Search backend decision
Postgres instead of Elasticsearch? It depends on your team.
For many teams, Postgres full-text search is enough. For some, Elasticsearch or Algolia is clearly the better call. The difference isn't the technology. It's your team, your scale, your budget and how much search matters to your customers. Below is a real analysis for one team, and what would change the answer for yours.
When each option is the right call
Check which list matches your situation best. That option is probably the right call for you.
- Basic typo tolerance via trigram matching is acceptable to customers
- p95 search latency stays under ~300 ms at 10M documents
- Search runs mostly within one tenant's document set
- No need for advanced faceting, synonyms UI or merchandising
- The team can dedicate at least a part-time engineer to cluster operations
- Search relevance is a core differentiator customers pay for
- Budget allows roughly $1k/month infrastructure plus operations time
- Data volume or query load outgrows a single Postgres instance
- Budget can absorb about $3-5k/month at 10M records
- Customers accept a third-party search subprocessor holding their data
- Instant, typo-tolerant search UX directly drives revenue or retention
- Documents fit record size limits without heavy chunking
One team's situation
This team asked Trade-off Analyzer the question below. Everything on the rest of this page comes from that real analysis, run in November 2026.
“We need to choose a search backend for our B2B SaaS product: Postgres full-text search vs Elasticsearch (self-managed on AWS) vs Algolia. 8 engineers, mostly Python/Django, already on Postgres 15 on AWS RDS. About 2M documents now, growing to 10M in 3 years, search used by about 5k daily users. Budget is tight, and nobody on the team has run Elasticsearch in production. 3-year horizon. Moving data out later would be painful, so treat it as hard to reverse.”
- Team
- 8 engineers, mostly Python/Django
- Stack
- Postgres 15 on AWS RDS
- Scale
- 2M documents now, 10M in 3 years; about 5k daily search users
- Budget
- Tight
- Experience
- Nobody has run Elasticsearch in production
- Horizon
- 3 years; moving data out later would be painful
Postgres search costs nothing extra, needs no new infrastructure the team has never run, and handles 10M documents. Its weaker relevance is a smaller risk than Elasticsearch's operational burden or Algolia's cost.
What mattered most to this team
Cost and simplicity were weighted highest because the budget is tight and nobody had run Elasticsearch. A team whose customers pay for great search would weight relevance higher, and could get a different answer.
| What mattersHow much | Postgres | Elasticsearch | Algolia |
|---|---|---|---|
| Cost (3-year TCO)High | 5 | 2 | 1 |
| Operational simplicityHigh | 5 | 1 | 4 |
| Search relevance & featuresMedium | 2 | 5 | 5 |
| Query performanceMedium | 3 | 4 | 5 |
| Security & tenant isolationMedium | 5 | 3 | 3 |
| Data consistencyMedium | 5 | 2 | 2 |
| ScalabilityLow | 3 | 5 | 4 |
| Evolvability & exit pathLow | 3 | 4 | 2 |
| Weighted totalout of 80 | 66 | 46 | 51 |
Scores from 1 (poor) to 5 (strong). The leader held in all 32 single-weight changes the analysis tested.
Risk at a glance
| Technical | Team | Timeline | Undo cost | |
|---|---|---|---|---|
| Postgres full-text search | Medium | Low | Low | Low |
| Elasticsearch (self-managed on AWS) | High | High | High | Medium |
| Algolia | Medium | Low | Low | High |
Why: Postgres full-text search
- Technical (medium). Ranking with ts_rank slows on broad queries with many matches; needs tenant-scoped indexes and result caps.
- Team (low). Plain SQL and Django ORM the team already uses daily; no new skills required.
- Timeline (low). No new infrastructure; a first version can ship within an ordinary feature cycle.
- Undo cost (low). Postgres stays the source of truth, so adding an external index later is additive work.
Why: Elasticsearch (self-managed on AWS)
- Technical (high). Shard sizing, mapping changes, JVM tuning and upgrades are new failure modes for a team without Elasticsearch experience.
- Team (high). Nobody has run it in production; on-call for a stateful cluster would land on one or two people.
- Timeline (high). Cluster setup, sync pipeline, security hardening and backups tend to surface complexity late.
- Undo cost (medium). Query DSL, sync pipeline and mappings are significant sunk work to unwind, though the source data stays in Postgres.
Why: Algolia
- Technical (medium). Sync pipeline, record size limits and per-tenant secured keys must be built and kept correct.
- Team (low). Managed service with a Django integration; little operational skill needed.
- Timeline (low). Fastest path to polished search UX if budget and data-residency approval are in place.
- Undo cost (high). Proprietary API, frontend widgets and relevance config create lock-in; price increases at 10M records are hard to escape.
What this team gives up
- Cost and simplicitySearch relevance
Postgres lacks native typo tolerance and BM25 ranking; trigram matching and weighted tsvectors close only part of the gap.
- Data consistencyDedicated search scale
Search reads transactional data directly, with no sync lag, but it shares RDS capacity with OLTP traffic.
- Tenant isolationSearch UX polish
Tenant filters stay in the same SQL query as the data, avoiding leak risk from a separate index.
Blue is what the choice keeps. Grey is what it gives up.
When to revisit
- Search latency at scalep95 search latency under 300 ms at peak; revisit if it exceeds 500 ms as documents approach 10M.
- Search qualityZero-result rate under 10% and rising click-through on top-3 results; track search complaints in support tickets.
- Database load from searchSearch uses under 25% of RDS CPU; move it to a read replica before exceeding that.
What would change the answer for you
The analysis rests on these assumptions about this team. If any is wrong for your situation, your answer may differ.
- Search is an important feature but not the product's main differentiator; users mostly search their own tenant's documents.
- Documents are mostly in languages with Postgres text-search dictionaries; heavy multilingual or CJK content would weaken the Postgres option.
- Average document is a few KB of searchable text; very large documents would need chunking in Algolia and more careful indexing in Postgres.
- Algolia cost estimated from public per-record and per-request pricing (roughly $0.40 per 1k records/month); at 10M records that is ~$4k/month before negotiation.
- Self-managed Elasticsearch means at least a 3-node production cluster (~$700-1,500/month on EC2) plus 0.25-0.5 FTE of operations time.
- Search load is ~50-150k queries/day, which RDS can absorb, if needed on a read replica.
- No customer contract or compliance rule forbids a third-party search subprocessor; if one did, Algolia would drop further.
- pg_search/ParadeDB-style BM25 extensions are not available on RDS, so they were not counted as part of the Postgres option.
Your team isn't this team.
Describe your team, stack, scale, budget and how much search matters to your customers. In a few minutes you get the choice that fits your situation, what you give up, the risks and when to revisit.
Get the answer for your team, free✓ 2 free analyses✓ No credit card✓ Sign in with Google
Questions
Is Postgres full-text search good enough?
For many teams, yes. In this analysis it won because it added no cost, no new infrastructure and no sync pipeline, and it handles 10M documents. It falls short when customers need typo tolerance beyond trigram matching, BM25-style ranking, advanced faceting, synonyms or merchandising, or when content is heavily multilingual or CJK.
When should you use Elasticsearch instead of Postgres?
When search relevance is a core differentiator customers pay for, when data volume or query load outgrows a single Postgres instance, and when you can dedicate at least a part-time engineer to running the cluster, with a budget of roughly $1k a month for infrastructure plus that operations time.
Is Algolia worth it?
When instant, typo-tolerant search directly drives revenue or retention and the budget can absorb its price. Estimated from public per-record and per-request pricing, that was about $3-5k a month at 10M records in this analysis. Customers also have to accept a third-party search subprocessor holding their data.
Can you move from Postgres search to Elasticsearch later?
Yes, and that makes starting with Postgres a lower-risk bet. Postgres stays the source of truth, so adding an external index later is additive work. The analysis recommends putting search behind an interface from day one, with a change-capture outbox as the planned path to a managed search service if thresholds are crossed.