Searches are up to 9x faster at higher limits

Until now, response times could climb sharply when you raised the result limit and asked for more companies or jobs in each query. We have optimized our backend so that requesting more results has a much smaller impact, and response times now stay much closer to constant as limits grow.

The improvement applies to searches in the app and through the API, and is especially visible at higher limits. Searches were about 3x faster overall, and the slowest company searches are now up to 9x faster.

Average response times by requested result limit:

• Limit 25: 4.08s before -> 1.99s after, about 2.0x faster.
• Limit 100: 7.76s before -> 2.62s after, about 3.0x faster.
• Limit 200: 12.27s before -> 3.25s after, about 3.8x faster.
• Limit 500: 34.68s before -> 5.25s after, about 6.6x faster across the company-search queries measured at this limit.

How we measured it

The figures shown summarize 160 end-to-end requests: 64 company-search requests and 96 job-search requests. We tested four company-search types across limits 25, 100, 200, and 500, plus eight job-search types across limits 25, 100, and 200.

For every search type and limit, we sent four requests: two to our production deployment and two to a preview deployment running the optimized code. The order alternated between preview -> production -> production -> preview and production -> preview -> preview -> production, so both deployments appeared at the beginning and end of a run. This reduces the influence of hot-versus-cold queries and other order effects. Each before value is the average of the two production requests, and each after value is the average of the two preview requests.

Both deployments connected to the same production database, so they used the same underlying data and normal live workload rather than isolated copies.

Each measurement covers the complete HTTP request and response, not only the database query. Exact response times can still be higher or lower at different moments as database load changes, so the figures are benchmark averages rather than latency guarantees.

Why higher limits benefit more

Finding the matching rows in our database is only part of the request. The API still has to fetch, join, and build the response object for every company or job it returns.

The optimized search path reduces the work needed to fetch and prepare each response. That matters most when the response contains hundreds of rows: the fixed request overhead stays similar, but the per-row savings compound.

Company searches

For company searches, the after run was faster or equal in all 16/16 measured rows. The largest gains appear at the higher limits, where the before numbers scaled up sharply and the after numbers stayed much flatter.

The benchmark covers common company search shapes: country filters, technology filters, job filters, and combined technology + job filters, measured at limits 25, 100, 200, and 500.

Each cell shows before -> after and the speedup for that limit. ✅ means the after run was faster or equal. Open a query to try the same measured filter shape in the app.

Job searches

Job searches were faster or equal in all 24/24 measured rows across limits 25, 100, and 200.

We measured title filters, keyword filters, description filters, recent-posting filters, and the same query shapes with 30-day posting windows.

Each cell shows before -> after and the speedup for that limit. ✅ means the after run was faster or equal. Open a query to try the same filter shape in the app.

What you need to do

Nothing. The improvements apply automatically in the app and through the API, with no workflow or integration changes required.