Replacing OpenSearch with PostgreSQL for a 25-million-record real estate data platform
Search that ran at a 3.1 second p90 on OpenSearch runs at 704 ms on PostgreSQL 18, validated row for row across 25 million records before cutover.
Industry: Commercial real estate data
Company size: 50-200 employees
Services: Database architecture, migration engineering, Kubernetes platform
The Challenge
The client runs a data and intelligence product covering millions of companies, contacts, and buildings. Search sat on a three-node OpenSearch cluster next to an Aurora database, and the two had to be kept in sync. The largest index held 34 million documents on a single 93 GB shard, which made resharding a multi-day project and tail latency painful: the 90th percentile query took over three seconds.
The team wanted one system of record, faster search, and a smaller bill, without rewriting the application's search semantics.
Our Approach
Rather than tune OpenSearch further, we proved out a replacement on PostgreSQL 18 with PostGIS and pgvector, running on the client's EKS platform.
- Built a loader and benchmark harness so every claim could be measured, not argued
- Wrote a query translator that maps the application's existing search requests onto SQL, so product code didn't have to change
- Replayed 1,200 real production queries against both systems and diffed the results
- Verified row-exact parity across the full corpus before any cutover planning
- Benchmarked PostgreSQL 18 against 17 for the index rebuilds the migration would depend on
The Results
- Row-exact parity across 25.2 million pages, 5.6 million contacts, and 4.5 million buildings, roughly 268 GB of data
- 4.4x faster at the tail, which is where users actually feel search speed
- Index rebuilds in 12 minutes on PostgreSQL 18 versus 59 minutes on 17, a difference that shaped the upgrade path
- One data store to operate, back up, and secure instead of two
The result is a validated path to retire OpenSearch entirely, with performance and correctness proven before any production traffic moves.
Key Takeaway
Search engines earn their complexity at web scale. At tens of millions of rows, a well-indexed PostgreSQL often wins on latency, cost, and operational simplicity. The trick is proving it with replayed production traffic before you commit.
Related guide: OpenSearch vs PostgreSQL for application search: when Postgres is enough
Running search on a system you'd rather not?
We'll benchmark the alternative against your real queries before recommending anything.