210 million records on one Elasticsearch index: How Anyone.com left Postgres in 1.5 weeks

Anyone.com, a global AI-powered real estate platform, replaced a Postgres search back end it had outgrown with Elasticsearch, moving 210 million production records onto a single index in about a week and a half and consolidating its entire search infrastructure into three lines of Terraform.

Anyone.com is a global real estate platform that ingests listings from third-party feeds and proprietary data and makes hundreds of millions of records searchable for real estate professionals and buyers. Its search back end started as Postgres on AWS RDS, but past tens of millions of records the ORM could not support the clustering the team needed, and a planned inventory expansion pushed the volume well past what that architecture could carry. Anyone.com rewrote its full query layer on Elasticsearch in about a week and a half, keeping the user-facing experience identical, and today runs 210 million production records on a single Elasticsearch Serverless index with roughly 95% of queries served by Elasticsearch. The same platform is the intended substrate for the vector search, RAG (retrieval augmented generation), and an agentic system the team is now building, all on infrastructure managed entirely in Terraform.

Anyone.com operates globally, indexing real estate data from dozens of sources into a search layer that real estate professionals and buyers query behind a login. The platform is built by a team of around 16 engineers on a multi-cloud footprint spanning GCP and AWS, joined by a high-availability VPN and managed entirely with Terraform. Data pipelines in Node, Java, and Python feed the search index; the front end is React and Next.js.

The pressure came from a single product decision. Anyone.com expanded the inventory it offered customers, and the record count climbed past the point where the existing Postgres backend could keep up.

Kian Aghaei, VP of engineering at Anyone.com, owns all of engineering with significant overlap into product and design, so the infrastructure call was his to make. The technology had stopped fitting the job.

Anyone.com started where many platforms start: a Postgres database on AWS RDS. This setup worked until the application outgrew Postgres’s structural limits.

The problem was clear. Past tens of millions of records, scaling meant clustering, and the application-layer ORM could not support the clustering the team needed. Stitching Postgres instances together added complexity and technical debt without solving the underlying problem, and for a platform operating globally, that debt was not something the team could carry for long. Volume was the root of it: Postgres did not scale past the tens-of-millions threshold the platform had already crossed.

A second requirement was forming at the same time. Anyone.com was building toward a vector search and RAG layer for an agentic AI system. Running a separate vector database alongside a search engine would have meant more operational surface and more points of failure. The team wanted one platform that could serve lexical search now and vector, RAG, and agentic retrieval later, without stitching a second system in beside the first.

Aghaei evaluated the field directly, and much of the decision came down to breadth rather than a single-capability win.

OpenSearch was the obvious contender. The AWS team backed it with offers of hands-on help and support, providing a real incentive to go with them. However, the decision belonged to Anyone.com, and it came down to the product. In his assessment, Elastic offered a faster pace of development than OpenSearch, backed by a considerably larger community.

Algolia and TypeSense he ruled out from direct prior experience, judging them capable but small at the scale Anyone.com already operated at. Aghaei is candid rather than dismissive here, and knows the TypeSense founder personally.

He also looked hard at pure-play vector databases and is straightforward about where they lead. On vector search specifically, he rates Pinecone slightly faster with a more sophisticated indexing method. But that alone did not settle it.

What Aghaei wanted most was everything in one place: one platform for lexical search now and features like vector search and RAG that the company could grow into, backed by a mature product and a well-supported community. That breadth was the deciding factor.

Data arrives from a mix of sources, including third-party feeds Anyone.com buys and receives updates from, and its own proprietary data. Apache Airflow pipelines, running mostly on GCP today, funnel everything to a single point. Records that clear a quality bar are ingested into Elasticsearch; the platform also stores data in Apache Iceberg and BigQuery, but the majority of qualified data lands in Elasticsearch. The production index is exposed to customers behind a login, where they search listings and drive insights from the results.

The migration approach was to replicate first, evolve later. The team rebuilt its existing queries on Elasticsearch using the official Node.js client and Painless scripts, with the explicit goal of keeping the user-facing interface and behavior identical to the Postgres version.

The hardest part was not a filter or a query at all, but the agent suggestion mechanism, an application-code ranking algorithm rather than a piece of SQL. Under Postgres, the database only narrowed the candidate set. The ranking itself ran in application code, combining weighted scores across several parameters with a listing-count decay and a handful of tie-breaking rules. Moving to Elasticsearch meant pushing that scoring into the engine with function_score and Painless so it could page server-side. Success was not whether the system returned the same rows, but whether every agent landed on the same score.

The full effort took about a week and a half. Postgres stayed live as a failover, and today roughly 95% of production queries are served by Elasticsearch, with two or three legacy Postgres back ends slated to be retired progressively.

Deployment ran through AWS Marketplace as self-service, no sales motion. Aghaei provisioned hosted Elasticsearch first and then migrated to Elasticsearch Serverless once it was clear the workload did not need the instantaneous response of a hosted cluster. The managed transition proved just as seamless as anticipated. Anyone.com runs two serverless projects, one for production and one for staging. Staging holds a single index of about 1.3 million listing records, and production holds 210 million and grows continuously as pipelines come online.

Today the entire Elasticsearch infrastructure is three lines of Terraform.

Technical highlights

• 210 million production records on a single Elasticsearch Serverless index, growing continuously
• Two Elasticsearch Serverless projects: production (210 million records) and staging (~1.3 million listing records)
• Retrieval today is lexical (BM25, the standard keyword-relevance ranking) only; dense vector, sparse vector with Elastic Learned Sparse EncodeR (ELSER), and RAG are on the near-term roadmap
• Ingest via Apache Airflow pipelines from third-party and proprietary sources
• Application integration via the official Elasticsearch Node.js client plus Painless scripts
• Multi-cloud footprint across GCP and AWS, high-availability VPN between them, managed in Terraform
• Full query layer migrated from Postgres in ~1.5 weeks, interface and behavior kept identical
• Entire Elasticsearch infrastructure defined in three lines of Terraform
• Whole-set queries at scale: a country-wide count drops from ~6.5 s on Postgres to 5 ms median (33 ms P95) on Elasticsearch

Cost moved in stages. Postgres on AWS RDS was inexpensive to begin with. Hosted Elasticsearch came in materially more expensive than that baseline. Moving to Elasticsearch Serverless changed the picture: It was the right fit for a workload where search sits behind a login and results can tolerate slightly longer response times in exchange for cost efficiency, and users are kept informed visually while a query runs. By Aghaei's account, the cost is now on par with, or a little above, what the team paid for Postgres, and that is before adding ELSER, RAG, or any of the advanced features. The current comparison is lexical-search-to-lexical-search, ahead of any of the vector or AI capabilities that were part of why Anyone.com chose the platform.

The moment the platform proved itself was early and concrete.

The gain shows up in the team's own benchmarks rather than in end-user metrics, and that was by design. Because the migration kept the user-facing experience identical, customers cannot tell the back end changed, so the performance difference over Postgres is captured internally, particularly at the threshold where Postgres would have required clustering the ORM could not support.

Single-record lookups were comparable on both engines, tens of milliseconds each, but Anyone.com's interface turns every map pan into an aggregation and every page into a count, exactly the whole-set operations Postgres struggled with as the table grew. A country-wide count that takes around 6.5 seconds on Postgres returns in 5 ms median on Elasticsearch, with a paginated page in about 180 ms. It also proved the platform could hold far more data than the old system ever did: The 210 million records now on Elasticsearch already exceed what the Postgres instance could carry.

Anyone.com already has what it set out to get from the migration: hundreds of millions of records searchable on one index, a full query layer rebuilt in about a week and a half, and an entire search infrastructure managed as a handful of lines of code. Today, production retrieval relies on lexical (BM25) search, providing a stable foundation at scale.

The forward plan builds directly on that baseline. The team is adding vector retrieval (ELSER) and RAG in the coming months, retiring two or three legacy Postgres back ends as confidence grows, and adopting Kibana for observability.

The larger goal is the most complex agentic system Anyone.com has planned, built with retrieval and RAG on the same Elasticsearch platform that serves search today.

The architectural payoff is concrete: Rather than bolting on a separate vector store for the AI layer, every query can point at a single back end that serves lexical (BM25), sparse retrieval with ELSER, and dense vectors, and combine them in one hybrid query. As the team builds its multi-agent system on top of this volume of data, semantic retrieval sits on the same platform as the search that already runs, not a second system beside it.

Aghaei emphasizes that Elastic is a real option for startups and mid-sized teams, especially if they are building agentic systems:

Anyone.com is a global AI-powered real estate platform, built by a small team, that connects buyers, sellers, and real estate professionals worldwide by indexing listings at scale and automating the transactions from start to finish. Your organization may not be indexing 210 million records today, but the same principles apply whether you are starting with a few million or scaling past a few hundred million: one platform that serves lexical search now and the vector, RAG, and agentic retrieval you will need next.

See how Elasticsearch handles hundreds of millions of records on a single index and gives you one platform for search, vector, and RAG, or start now with a free trial.

• Elasticsearch
• Vector database
• ES|QL
• Elastic Agent Builder
• Elasticsearch Labs
• Elastic docs

Topics: Elasticsearch, Elasticsearch Serverless, BM25 lexical search, Postgres migration, single-index scale, Apache Airflow ingest, vector search roadmap, RAG, agentic systems, Terraform, real estate, Software & Technology