Migrating AWS Elasticsearch to Typesense on Cloudflare Workers
How to evaluate a search migration from AWS Elasticsearch to Typesense with Cloudflare Workers as the API edge.
A search migration works when index shape, query paths, sync jobs, and rollback plans are designed before any production cutover.
Start with query reality
Search migrations fail when teams copy indexes without understanding the product queries. I begin by listing filters, sort modes, ranking requirements, typo tolerance, permissions, pagination behavior, response size, and the screens that depend on search. This matters because Elasticsearch indexes often grow organically over time. Typesense works best when the schema is deliberately shaped around the actual product experience.
Use Workers as a narrow edge API
Cloudflare Workers are a strong fit for request validation, cache-aware routing, multi-tenant guards, and response shaping. Keeping that layer narrow makes search behavior easier to test and rollback. The Worker should not become a second search engine. It should protect the search service, normalize client requests, enforce safe limits, and return predictable response shapes to the frontend.
Index design comes before infrastructure
Before infrastructure choices, define collections, fields, faceting behavior, sorting strategy, typo tolerance, synonyms, and tenant boundaries. Search quality problems are often schema problems. If the product needs filtering by status, location, owner, category, and permissions, those requirements must appear in the index design before the first production sync job runs.
Plan the sync path carefully
The hard part of replacing Elasticsearch is usually not serving the first query. It is keeping the new index correct over time. I prefer an explicit sync path: initial backfill, incremental updates, delete handling, retry behavior, and monitoring for drift between the source database and the search index. Without this, teams end up debugging missing results after users already notice them.
Protect the search endpoint
Search endpoints are easy to abuse accidentally. A frontend bug can create expensive query patterns, wide filters, or excessive pagination. The edge API should cap page size, validate filters, reject unsupported sorts, and log suspicious query shapes. These protections are small, but they prevent a search migration from turning into a new reliability problem.
Compare relevance, not just latency
A faster search result is not automatically a better search result. Before switching production traffic, compare top results for common searches, empty-result behavior, typo handling, filtering correctness, and how business rules affect ranking. Product owners should review real examples because they understand when a search technically works but feels wrong to users.
Cut over with evidence
Before switching production traffic, compare result quality, p95 latency, indexing delay, error rate, operational cost, and rollback time. The migration is only done when the new path is cheaper or simpler without hurting search relevance. If possible, route a small percentage of read traffic through the new path first and compare logs before making it the default.
Where the cost savings usually appear
The cost improvement often comes from reducing the managed search footprint and simplifying the API layer around it. Elasticsearch can be excellent, but it is frequently overkill for products that need fast faceted search, typo tolerance, and predictable filtering. Typesense can be a better fit when the product requirements are narrower than the operational weight of the existing search cluster.
What I would document for handoff
A search migration should leave behind a short operating manual: collection schemas, sync job behavior, known query examples, rollback steps, dashboard links, and guidance for adding new filters. This is what keeps the migration from becoming tribal knowledge. The next engineer should be able to change a searchable field without reverse-engineering the entire system.
Backfill strategy matters more than the first demo
The first demo usually indexes a small sample and looks fast. Production backfill is different. It needs batching, progress tracking, retry handling, memory limits, and a way to resume after failure. If the source database contains millions of records, the backfill should not lock tables or overwhelm the API. I prefer a controlled job that records checkpoints and can be paused, resumed, and inspected. That turns a risky migration event into an operational process.
Shadow traffic reduces launch risk
Before exposing the new search path to users, the backend can send shadow queries to Typesense while still returning Elasticsearch results. This lets the team compare latency, result counts, error rates, and top matches without changing user behavior. Shadow traffic is especially useful when search affects revenue, discovery, support operations, or internal productivity. It gives the team real evidence from production query shapes instead of relying only on test fixtures.
Tenant and permission boundaries must be explicit
Search is dangerous when permissions are implicit. If a product has teams, customers, roles, regions, or private records, the index must include fields that make access control enforceable. The edge API should apply those filters automatically instead of trusting clients to send them. This makes the safe query path the default path. It also protects future developers from accidentally building a screen that can discover records outside the current user scope.
A phased launch plan
A practical launch plan has five phases: schema design, backfill, shadow comparison, limited read traffic, and full cutover. Each phase should have a rollback condition. For example, if result mismatch crosses an agreed threshold, stop the cutover. If p95 latency regresses, inspect query patterns before expanding traffic. If indexing delay grows, fix the sync path before adding more users. This sounds cautious, but it is much faster than recovering from a broken search launch.
How to decide whether Typesense is enough
Typesense is a strong fit when the product needs fast full-text search, faceting, typo tolerance, filtering, and simpler operations. It may not be enough when the product depends on advanced analytics, complex aggregations, highly customized scoring, or deep Elasticsearch-specific features. The right question is not "which search engine is better?" The right question is "which search engine fits the product requirements with the least operational weight?"
The maintenance win
A successful migration should make future changes easier. Adding a searchable field, adjusting a filter, or debugging a missing result should be understandable to a backend engineer who did not perform the migration. That is why I care about small schemas, explicit sync jobs, narrow edge APIs, and written examples. Search touches the product experience directly, so maintainability is part of search quality.
Next step
Need this decision made for your backend?
Send the current architecture, traffic shape, and cost pressure. I can turn that into a short migration or audit plan.
Request an architecture review