How to diagnose search performance problems in a growing B2B SaaS product

Your search features are fast when you only have a few hundred records, but as your B2B SaaS scales, search can become an application performance bottleneck if it isn't optimized.

Hundreds of records can turn into millions. If users start complaining about performance, engineering might suggest adding hardware to compensate, increasing infrastructure costs before identifying the main cause of slow search.

Optimization becomes necessary to keep users happy, keep your infrastructure bill within budget, and ensure your SaaS product's longevity so users can find the right information across large datasets.

In this article, we will discuss the framework that best helps B2B SaaS companies troubleshoot search performance issues.

Instead of jumping into expensive fixes, we will give you a roadmap for troubleshooting common issues and optimization options.

What "fast search" actually means

Professionals often talk of "fast search," but it means different things to different people.

Users think of "fast" as the speed at which they see results after typing a query. They want shorter response times, because most people equate "search" with fast search engines like Google or Bing.

For backend engineers, on the other hand, "fast search" is determined by different dimensions:

• Query latency: How long a search engine takes to process a query.
• Indexing latency: How quickly new documents become searchable after they enter the system.
• Network latency: How long requests take to travel between the user, the app, and the search infrastructure.
• Availability and recovery: Whether search is accessible during upgrades or infrastructure failures.
• Performance under load: Whether response times remain good as data volume and query traffic grow.

A problem in any of these categories can feel identical to the end user.

For example, a user in a distant region might wait several hundred milliseconds for results because of network latency, even though the search engine executes the query almost instantly.

That is why you shouldn't treat response time as an end-all-be-all metric. Diagnosing "slow search" starts by identifying which part of the search experience is breaking down.

The decision framework: what to fix when search starts breaking

When search starts breaking, you need a framework for checking what's wrong.

Broken search features can include a variety of issues, and any one of them can cause a domino effect. If you aren't experienced with fast search issues, you might start at the last step in troubleshooting – looking for solutions without first identifying the issue – which costs money and puts more overhead on your engineering management.

Here is a table of issues and where to start troubleshooting.

*Enterprise capability, configured with our team. Replication covers read availability; write failover is not included. Geo-replication is available today for replication-only setups.

Slow search, cause unknown

Latency (especially for a small business scaling up rapidly) is a common first issue a SaaS product faces.

Engineers might think the best way to handle this is to expand infrastructure horizontally, like adding nodes, clusters, or implementing sharding.

The problem is that this solution isn't always optimal; it adds unnecessary infrastructure complexity and requires more engineering management before you even discover the cause of the latency.

Here is what to do instead:

• Confirm that the slowdown is actually inside search. This is best done by reproducing a few queries that users have experienced as slow and comparing the total request time with the time spent inside the search engine. If the search engine is responding quickly but the users are still experiencing "slow search", the issue might be in the application itself or the network.
• Run a performance trace to see which part of the request takes the most time. In Meilisearch Cloud, open the Search preview tab for your project and toggle Performance trace in the top-right of the results panel. The trace breaks down how much time the request spends at different stages of the search pipeline, helping you identify where the latency is coming from.

• Use the slowest stage to decide what to investigate next. Rely on the following for more specific diagnostics:

• Change only one thing. Once you've identified the likely bottleneck, make the smallest relevant configuration change and rerun the same queries. Changing more than one thing makes it harder to compare the before and after.
• Only consider more capacity once configuration is no longer the limiting factor.

Slow indexing

As records are added, they must be indexed in order to appear in user search results. If queries execute quickly but search still feels slow, indexing latency may be the issue.

There is no universal metric for indexing latency. Don't assume that new records should be indexed within a fixed number of (milli)seconds; instead, measure how long updates normally take for your system and investigate when that delay starts increasing.

Here are your diagnostic steps if you suspect indexing latency:

• Check the task queue depth to see whether indexing work arrives faster than it is processed. If it is, determine why. In Meilisearch, indexing operations are automatically added to an asynchronous task queue, and its task APIs let you inspect queued/processing operations.
• Check whether you're sending documents one at a time. Fewer, larger payloads are more efficient because every HTTP request creates a task and small requests add overhead.

• If the queue isn't the problem but batches take a long time to process, inspect where that time goes. In Meilisearch, use an individual batch's progressTrace to identify which indexing phase dominates. It can distinguish things such as extracting words, building filter/facet structures, waiting for database writes, or waiting on CPU-bound extraction.
• Finally, ensure that you have configured the ranking rules, filterable attributes, and searchable attributes before adding documents. Changing them later will trigger a full reindex of all documents.

Slow search for users in distant regions

Not every user will be close to your data center. You might hear from users in distant regions complaining about performance, while those close to your instance see great performance.

This is where network latency becomes the focus of the investigation. A query might take only a few milliseconds in the search engine, but the end-to-end response time is much longer because it has to travel between the user, your application, and a search instance in another region.

Here are the diagnostic steps to take here:

1. Check whether latency complaints cluster in particular countries or regions. If users near the search instance consistently get faster responses than users farther away, network latency is most likely the problem.
2. Determine where the request time is actually being spent. Look at:
   1. Search engine processing time: How long it takes the engine to execute the query.
   2. Application/API time: How much additional time your application spends handling the request before and after search.
   3. Total user-observed response time: How long the complete request takes from the user's perspective.
   4. User and instance region: Whether the slower requests consistently involve users farther from the infrastructure serving search.
3. Compare otherwise similar requests from users or test locations in different regions. If engine-side processing stays similar but total response time increases for distant users, network round trips are the likely reason for slow search.
4. Once you confirm network latency, reduce the distance the request has to travel.

For a user base concentrated in one area, this may mean choosing a cloud region closer to those users.

If your users are distributed across several regions, serving search from multiple geographic locations can reduce round-trip time.

With Meilisearch, one option is geo-replication, which places replicas containing the same data in different regions. Your application then sends each user's queries to the nearest replica. Meilisearch Cloud currently offers geo-replication. This is an enterprise capability, configured with our team. Replication covers read availability; write failover is not included. Geo-replication is available today for replication-only setups.

Slow search at scale

Although other issues are more likely, sometimes you simply outgrow your current infrastructure and need an upgrade.

If you've fine-tuned your search configuration, run other diagnostic tests (and potential solutions), and are still seeing "slow search", it's time to find out where your current instance tops out.

Here's how to do that:

1. Rule out the query, filtering, indexing, and response-size issues covered earlier. Yes, this bears repeating, as it's crucial before you start looking at capacity.
2. Check CPU usage, memory pressure, request throughput, indexing throughput, and p95 or p99 latency under a realistic workload. Look for the moment where a single instance can no longer maintain the response times or indexing throughput that your application requires.

An important thing here is not to treat your dataset size or RAM usage alone as proof that you need to upgrade your infrastructure. You need to test whether the current instance can keep up with your actual workload.

3. Consider whether a larger single instance is enough. If more CPU, memory, or other resources give you sufficient headroom, vertical scaling keeps the architecture simpler.
4. If a tuned and appropriately sized instance still cannot handle your required data volume or search traffic, consider sharding.

Sharding splits an index across multiple instances so each instance stores and processes only part of the dataset. Searches run across the shards and the results are combined into one ranked response.

In Meilisearch Cloud, sharding is the horizontal-scaling option for workloads that have moved beyond what a single instance can handle at acceptable performance.

Enterprise capability, configured with our team. Replication covers read availability; it does not include write failover. Geo-replication is available today for replication-only setups.

Search drops during upgrades or node failure

All of the issues above are related to how quickly search responds or how quickly data becomes searchable. However, as search becomes more critical to your product, you have to ask yourself: what happens when one of your search instances becomes unavailable?

It could be a node failure, a planned restart, or an upgrade, but if your search goes offline because you lose a node, no amount of query optimization will help.

Here is how to diagnose this problem:

1. Check what happens when one search instance goes offline. If users can no longer run searches until that instance comes back, your deployment has a single point of failure for reads.
2. Separate read availability from write availability.

Read availability means users can continue searching existing indexed data when a node is unavailable. Write availability means new and updated data can continue being indexed during the same period.

Decide which guarantee your application actually needs. For example, temporarily serving slightly stale search results may be acceptable during a short maintenance period.

3. Add replication if search reads need to remain available. Replication keeps copies of the same search data on multiple instances.

In Meilisearch Cloud, replication provides high read availability and automatic failover.

During an upgrade that requires an instance to restart, another replica can continue serving searches, avoiding the brief interruption a single-instance deployment would experience.

Enterprise capability, configured with our team. Replication covers read availability; write failover is not included. Geo-replication is available today for replication-only setups.

Please note that Meilisearch currently provides read high availability through replication, but not high write availability. You also need to check whether you need write failover.

How to evaluate whether your document search is ready to scale

Okay, but what about scaling infrastructure? How can you tell that your current setup genuinely can no longer support your product growth?

First, establish a baseline for how search performs today. Monitor the limits of your current system and whether you're consistently approaching them.

Before making the final decision to scale infrastructure, ensure that:

1. Your configuration is fully tuned using the framework above.
2. Your workload tests show continual resource pressure.
3. Your current instance no longer has enough headroom for growth.

Lastly, check:

• Are response times degrading under realistic load? Track typical and tail latency, such as p95 or p99, rather than relying only on averages. Look for a consistent increase as query volume or concurrent usage grows.
• How much capacity headroom do you have? Monitor CPU, memory pressure, request throughput, and indexing throughput. Occasional spikes are different from sustained resource pressure during normal or expected peak traffic.
• Is indexing keeping up with incoming data? Watch task queue depth and indexing lag. A queue that consistently grows faster than it clears can indicate that your current setup is approaching its indexing capacity.
• What happens under your expected future workload? Load-test representative queries and indexing operations at the traffic and data volumes you expect as the product grows, rather than sizing infrastructure only around today's usage.
• Can the current setup meet your reliability requirements? Consider whether a node failure or planned upgrade would interrupt search, and whether that level of availability is still acceptable as search becomes more important to the product.

Stop treating every search problem like an infrastructure problem

When search starts slowing down or becoming harder to manage, the knee-jerk reaction might be to add more resources.

However, instead of adding to your infrastructure budget, start by diagnosing what is actually breaking. Look at configurations, pipeline bottlenecks, indexing, instance limits, and similar issues.

Monitoring will help with troubleshooting, so make sure you have monitoring that can distinguish between infrastructure and configuration issues.

It will also help you troubleshoot faster and catch errors before they bubble up to customers and cause downtime.

Find the right scaling path with Meilisearch

Meilisearch is built around scaling fast search without unnecessary infrastructure overhead. It includes latency tuning, an asynchronous task queue, batched document additions and updates, and more.

If you're struggling to scale your B2B SaaS and expensive infrastructure seems like the only solution, let Meilisearch optimize your search features without the overhead. Request a demo, and let's discuss faster search.