Timescale's BM25 Bombshell Just Broke Postgres Search

Last summer, Timescale faced a choice: bolt on a proprietary search engine or build the fastest open-source BM25 for Postgres. They chose the latter—and just shipped pg_textsearch, a ranked keyword search extension that claims to beat Elasticsearch on both speed and cost.

Timescale open-sourced pg_textsearch, a Postgres extension for BM25-ranked keyword search that claims to be faster than Elasticsearch.
The extension completes a hybrid search stack (pgvectorscale + pg_textsearch) that lets Postgres handle both semantic and keyword search without external services.
This move commoditizes a core search capability and threatens proprietary search vendors like Elastic and MongoDB.

Why Did Timescale Build Yet Another Search Engine?

Timescale, best known for time-series databases, faced a strategic fork last summer. To grow into AI workloads, they needed hybrid search—semantic + keyword—without leaving Postgres. They had already built pgvectorscale for vector search. The missing piece was a production-grade ranked keyword search. Instead of integrating Elasticsearch (the incumbent) or paying for a proprietary service, they built pg_textsearch from scratch. The result is a Postgres extension that implements BM25 with faster indexing and querying than Elasticsearch, according to their benchmarks. This is not a hobby project; it is a deliberate land-grab for the AI search stack.

Who Should Be Scared of a Faster BM25 in Postgres?

Elastic should be terrified. For years, Elasticsearch has been the default for full-text search, but its architecture is showing age—complex sharding, high memory overhead, and a painful learning curve. pg_textsearch, by contrast, runs inside Postgres, uses standard SQL, and requires zero new infrastructure. Timescale claims it indexes 4x faster and queries 2x faster than Elasticsearch on comparable hardware. MongoDB's Atlas Search, built on Lucene, faces the same vulnerability. If developers can get superior performance from their existing Postgres database, why pay for a separate search cluster?

Timescales BM25 Bombshell Just Broke Postgres Search

How Does pg_textsearch Compare to the Incumbents?

Feature	pg_textsearch (Timescale)	Elasticsearch	MongoDB Atlas Search
License	Open source (PostgreSQL)	SSPL (source-available)	Proprietary
Indexing speed	~4x faster (claimed)	Baseline	N/A
Query latency	~2x faster (claimed)	Baseline	N/A
Integration	Native Postgres SQL	REST API, separate cluster	Native MongoDB
Hybrid search	Yes (with pgvectorscale)	Requires third-party tools	Limited
Verdict	pg_textsearch wins on speed, simplicity, and cost for Postgres users. Elastic retains an edge in multi-language support and ecosystem maturity, but the gap is closing fast.

What Does This Mean for the AI Search Stack?

Every AI application needs retrieval—either semantic (vectors) or keyword (BM25). Until now, teams had to stitch together pgvector for vectors and Elasticsearch for keywords, or pay for a managed service like Pinecone that does both. Timescale's pgvectorscale + pg_textsearch combo offers a single open-source stack that runs on any Postgres instance. This is a direct assault on Pinecone, Weaviate, and Qdrant, which have built entire businesses around vector search. If Postgres can do both vectors and BM25 at comparable performance, why would a startup pay 10x for a specialized database?

Who Benefits Most From This Open-Source Bombshell?

Developers and SMBs win immediately. They get enterprise-grade search without licensing fees or infrastructure complexity. Cloud providers like AWS (RDS) and Google (Cloud SQL) benefit because pg_textsearch increases Postgres' stickiness—once a team adopts it, they are less likely to migrate to a rival database. The losers are clear: Elastic, MongoDB, and any vendor that charges a premium for search. Timescale itself wins by positioning its cloud as the go-to for AI workloads, even if pg_textsearch is open source. The real monetization comes from managed Postgres services, not licensing.

My thesis is simple: pg_textsearch is the most important Postgres extension of 2026 because it kills the last reason to run a separate search engine. I have seen this playbook before—Timescale commoditized time-series with TimescaleDB, and now they are doing it for search. Short-term, Elastic will dismiss the benchmarks as cherry-picked. Long-term, they will lose the low-end and mid-market as Postgres absorbs search. The big winner is the Postgres ecosystem; the big loser is Elastic, which now needs to justify its premium pricing against a free, faster alternative. I predict Elastic will acquire a Postgres search startup or build its own Postgres extension by Q1 2027 to counter this threat, because their SSPL license already alienated some of the community.

Predictions

Elastic will respond by releasing a Postgres-compatible search extension or acquiring a startup in the space by Q1 2027.
By Q3 2027, at least two major cloud providers (AWS, GCP) will offer pg_textsearch as a managed extension in RDS and Cloud SQL.
Pinecone will lose 15-20% of its early-stage startup customers to Postgres-based hybrid search by end of 2027.

Summer 2025
Timescale identifies hybrid search gap
Timescale decides to build its own BM25 implementation for Postgres instead of integrating Elasticsearch.
Late 2025
pgvectorscale ships
Timescale releases pgvectorscale for scalable semantic search beyond pgvector limits.
March 2026
pg_textsearch open-sourced
Timescale open-sources pg_textsearch, a Postgres extension for BM25-ranked keyword search.

Timeline

Summer 2025 — Timescale identifies the need for hybrid search in Postgres.
Late 2025 — pgvectorscale ships for semantic search.
March 2026 — pg_textsearch (BM25) open-sourced on GitHub.

Article Summary

pg_textsearch is not just a faster BM25—it is a strategic move to make Postgres the default OS for AI search.
Elastic and MongoDB are the biggest losers because their search tiers are now both slower and more expensive than a free Postgres extension.
The hybrid search stack (vectors + keywords) in Postgres threatens standalone vector databases like Pinecone and Weaviate.
Timescale's real monetization is through its managed cloud, not licensing—a classic open-core play.
Expect Elastic to fight back by either releasing a Postgres extension or acquiring a competitor within 12 months.