How to Build a SaaS Search Feature That Doesn’t Become a Performance Disaster at Scale

Search is the feature founders consistently underestimate. It looks simple – users type something, results appear – and so it gets scoped as a two-day task, usually in the last week before launch. Then six months later it’s the number one support complaint, the number one reason activation drops, and the number one thing holding back the enterprise deals that need “proper search” as a baseline requirement. We’ve seen this play out enough times that it’s now one of the first things we pressure-test in any SaaS scoping conversation.

The core problem isn’t that search is hard to build. It’s that the architecture decision you make at week two determines your ceiling at month eighteen. Choose wrong and you’re not refactoring – you’re rebuilding from scratch under pressure, while your best customers are losing patience.

The Three Search Architectures (and When Each One Breaks)

When we’re scoping a SaaS build, there are really three viable paths for search, and they’re not interchangeable.

Database-native search – using Postgres ILIKE, tsvector/tsquery full-text, or MySQL FULLTEXT – is the right call for early-stage products with modest data volumes and simple query patterns. It’s free, already inside your stack, and ships fast. The ceiling is low: around 50,000-200,000 records depending on complexity, after which query times start creeping above 300-500ms and your database starts working harder than it should. The other limitation is relevance. Postgres full-text is keyword-matching. It doesn’t understand that “invoice overdue” and “unpaid bill” are the same thing. That matters a lot when your users aren’t entering exact terms.

Dedicated search infrastructure – Elasticsearch, OpenSearch, Typesense, Meilisearch – is the right call once you know search is a core product surface, not a nice-to-have. Typesense and Meilisearch are dramatically easier to operate than Elasticsearch, and for most Australian SaaS products they’re more than sufficient. Typesense in particular has become our default recommendation for early-to-mid scale: it’s fast, the relevance tuning is straightforward, and the hosting cost is manageable ($50-$300/month on a decent dedicated node). Elasticsearch is powerful but it’s also operationally heavy – we’d only reach for it when the query complexity or data volume genuinely demands it.

AI-powered semantic search – embedding your content, storing vectors, querying by similarity – is increasingly accessible but frequently oversold. It’s genuinely useful when your users are searching conceptually rather than by keyword. A knowledge base, a document library, a support portal. It’s overkill for transactional search (“find invoice #4821”) and it adds latency and cost that you need to budget for deliberately. We’ll get to the numbers shortly.

The Indexing Architecture Nobody Thinks About Early Enough

Here’s the mistake we see most often: founders pick their search engine, wire it up to the database, and consider it done. What they’ve missed is the sync layer – the mechanism that keeps the search index accurate as data changes.

There are three real approaches:

• Synchronous indexing: update the index in the same transaction as the database write. Simple, but it ties your write performance to your search infrastructure. If your search node has a hiccup, your writes degrade too. Not acceptable in most production contexts.
• Event-driven indexing: emit an event on every meaningful data change, consume it asynchronously, update the index. This is cleaner architecturally – your writes are never blocked by search – but it means your index is eventually consistent. Users might search for a record they just created and not see it for two to five seconds. That’s usually fine. Sometimes it isn’t. You need to decide upfront.
• Polling/batch sync: a background job re-indexes changed records on a schedule. Cheap to build, easy to reason about, and genuinely appropriate when search freshness isn’t critical. Reporting dashboards, historical data, catalogue-style products. The failure mode is that it drifts without anyone noticing – you need monitoring on index lag or you’ll discover the problem via a customer complaint.

For most of what we build, event-driven indexing wins. It’s the approach that scales without architectural surgery later. But it requires a reliable event bus – SQS, Redis Streams, or similar – and you need to handle re-indexing failures gracefully. Dropping a failed index job silently is how you end up with a search index that quietly diverges from reality over weeks.

Relevance Tuning: The Work That Actually Makes Search Good

Shipping search infrastructure is maybe 40% of the job. The other 60% is relevance – making sure the right results surface for real user queries, not just technically correct matches.

For dedicated search engines, the levers are:

• Field weighting: a match on a contact’s name should rank higher than a match in their notes. This sounds obvious but most default configurations treat all fields equally.
• Typo tolerance: Typesense and Meilisearch handle this well out of the box. Elasticsearch requires explicit configuration. Test with real query logs, not sanitised demo data.
• Synonyms: for B2B SaaS especially, your users will use industry-specific terminology that doesn’t match your field labels. Build a synonym dictionary early and keep it maintained.
• Boosting by recency or business logic: in most B2B tools, a record modified last week is more relevant than one from three years ago. Wire that in as a scoring factor, not an afterthought.

The honest truth is that relevance tuning is iterative. You need real query data to do it well. We typically build a basic logging layer alongside search – what users searched, what they clicked, what they abandoned – so there’s something to work with after launch. Without that data, relevance tuning is guesswork.

What AI-Powered Search Actually Costs in Practice

If you’ve decided semantic search is the right call, here’s what you’re actually signing up for.

The core components: an embedding model (OpenAI text-embedding-3-small is $0.02 per million tokens – cheap for most use cases), a vector database (Pinecone, pgvector in Postgres, Qdrant, or Weaviate depending on your existing stack), and a query pipeline that embeds the user’s search term, retrieves nearest neighbours, and optionally re-ranks results before display.

For a product with 100,000 searchable records of moderate length, you’re typically looking at a one-time embedding cost of $10-$50 depending on content volume, then ongoing costs driven by query volume. At a few thousand searches a day, you’re probably under $100/month in embedding costs – that’s not the budget problem. The budget problem is the vector database. Managed Pinecone at meaningful scale runs $70-$400/month depending on index size and query throughput. pgvector is free if you’re already on Postgres and your scale is modest, but it starts to creak above a few hundred thousand vectors without careful indexing.

The latency consideration is real too. A semantic search pipeline – embed query, nearest-neighbour lookup, re-rank – adds 200-800ms compared to a keyword search that returns in under 50ms. For most use cases that’s acceptable. For an autocomplete-as-you-type experience, it isn’t. Hybrid approaches – keyword search for speed, semantic for fallback or disambiguation – often give you the best of both, but they’re also twice the infrastructure to manage.

Multi-Tenancy and Search: The Access Control Problem

This is where a lot of SaaS search implementations break in ways that are genuinely dangerous rather than just annoying.

In a multi-tenant product, your search index contains data from every customer. If your access control layer is in your application but not enforced at the index level, you’re one query construction bug away from returning records across tenant boundaries. We’ve audited existing codebases where this was happening silently – results were filtered in the application layer after retrieval, which works until someone passes an unexpected parameter.

The right approach depends on your search engine. Typesense supports scoped API keys that filter by tenant ID server-side. Elasticsearch has document-level security. For most SaaS products, the cleanest pattern is separate indices per tenant if your tenant count is manageable (under a few hundred), or a single index with mandatory tenant ID filtering enforced in your query construction layer – and tested with explicit cross-tenant query attempts in your test suite, not just assumed correct.

If you’re building a product that will handle sensitive data – health, finance, legal – get the access control layer audited before you launch, not after. This is not an area to cut corners on and fix later.

The Build Cost Reality

To put rough numbers on it: integrating database-native full-text search into an existing Postgres-backed SaaS typically runs $3,000-$8,000 in build time depending on complexity. Integrating a dedicated engine like Typesense with event-driven indexing, basic relevance configuration, and a logging layer is more like $12,000-$25,000. A semantic search pipeline built properly – embedding pipeline, vector storage, hybrid retrieval, access controls – starts at $20,000 and can run to $50,000+ for complex implementations.

Those ranges assume a product that’s already live and has an existing data model. Greenfield is faster. Retrofitting a mature, complicated schema is slower.

The cost that surprises founders most is the ongoing relevance work. Good search doesn’t stay good on its own – it needs someone reviewing query logs, adjusting weights, expanding synonyms, and testing edge cases. Budget for that as a recurring line item, not a one-time project.

If you’re unsure which approach fits your product – or you’ve already shipped something and suspect it won’t hold up – talk to Amora about your build before the architecture decision gets made by default rather than by design.

The products that get search right treat it as a core feature with real engineering investment behind it. The ones that get it wrong treat it as plumbing. Users always know the difference, even when they can’t articulate why.