The "we need search" conversation almost always starts the same way: someone has been doing FilterExpression scans on DynamoDB and the latency has gotten embarrassing. The default reach is OpenSearch. The default outcome is a four-figure-per-month line item that the team never quite uses to its potential.
This post simulates three real options — full OpenSearch, DynamoDB Streams piped into a denormalised search table via Lambda, and Algolia (or any external search SaaS) — and unpacks where the crossover lives.
The three options
- OpenSearch (Amazon managed) — full Lucene-based search. Free-text, fuzzy, faceting, ranking. Highest capability, highest baseline cost.
- DynamoDB Streams + Lambda → secondary table — denormalised projections and prefix queries via GSIs. Cheap and fast for exact-match and prefix search. Useless for true relevance ranking.
- Algolia / Typesense Cloud — SaaS search. Excellent developer experience, sub-50 ms p95. Costs scale with records and queries.
Cost at three product sizes
From a pinpole canvas simulation with 100 char average document size, mixed read/write profile:
| Product size | OpenSearch | Streams+Lambda | Algolia |
|---|---|---|---|
| 100K docs · 10K queries/day | $220/mo | $18/mo | $90/mo |
| 1M docs · 100K queries/day | $380/mo | $95/mo | $340/mo |
| 10M docs · 1M queries/day | $1,640/mo | $680/mo | $2,100/mo |
| 50M docs · 10M queries/day | $6,200/mo | $3,400/mo (degraded UX) | $9,500/mo |
The freshness trade-off
Cost is half the picture. Freshness is the other half:
OpenSearch
Near-real-time indexing (~1s refresh). Sub-second query latency at scale. Capable of complex relevance models.
Streams + Lambda
Eventually consistent (~2–5s). Excellent for prefix and exact-match. Cannot do free-text or relevance ranking without external help.
Algolia / Typesense
Sub-50ms p95 globally. Best-in-class typo tolerance and ranking. Vendor lock-in and per-record pricing.
A decision rule that holds
- Pick Streams + Lambda when your queries are exact-match, prefix, or filtered lookups. "Find users by email prefix" does not need OpenSearch.
- Pick OpenSearch when you need free-text, faceting, custom scoring, or geospatial — and when you have someone who will own cluster ops. Reserved instances and gp3 storage matter.
- Pick Algolia/Typesense when you want sub-50 ms p95 globally and developer ergonomics matter more than per-query cost — typical for product-facing search on growth-stage SaaS.
At least half the OpenSearch clusters we see in customer simulations could be replaced with a DynamoDB GSI and a denormalised projection. The team picked OpenSearch because "we'll need real search eventually." Eventually rarely arrived.
Running this on pinpole
Drop the search service node on the canvas, configure document count, query rate, write rate, and average doc size. Swap between OpenSearch (with instance class and storage), Streams+Lambda (with GSIs sized to the projection), and a SaaS node. The simulator returns cost, write-to-search latency, and read latency at percentile. Three runs cover most decisions.
"We need search" should not auto-translate to "we need OpenSearch."
Simulate all three patterns with your real document and query profile. The cheapest option that meets your latency SLO usually wins.
Start 14-day free trial →