An open-source Postgres extension that does what teams used to spin up an entire Elasticsearch cluster to get - full-text search and analytics, ranked, fast, and inside the database.
Somewhere right now, a backend engineer is staring at a diagram with two boxes and an arrow. On the left, Postgres - the source of truth. On the right, Elasticsearch - the place that actually does search. The arrow between them is a pipeline, and the pipeline is where the bugs live.
ParadeDB exists to erase that arrow. It is an open-source PostgreSQL extension that brings ranked full-text search and columnar analytics directly into the database you already trust with your data. No copying. No nightly sync that drifts out of date. No second system to staff at 3 a.m. The company is small - around ten people, headquartered in New York - but its software is installed more than a hundred thousand times and starred by nearly nine thousand developers. For an infrastructure project barely out of its first birthday, that is not a rounding error.
Postgres is becoming the default database of the world, and you still can't do good search over that information.
Philippe Noel, co-founder & CEOPostgres is very good at almost everything. Search is the embarrassing exception. Its built-in text search works until your users expect relevance ranking, typo tolerance, faceting, and sub-second results across millions of rows - which is to say, until your users expect search.
So the industry settled on a workaround that everyone tolerates and nobody loves: run Postgres for truth, run Elasticsearch for search, and build a pipeline to ship data from one to the other. It works. It also doubles your operational surface, introduces a window where the two systems disagree, and quietly turns "add a search box" into a distributed-systems project. The irony is hard to miss - to make one database searchable, you adopt a second database, and then you spend your weekends keeping them on speaking terms.
The biggest feature ParadeDB ships is the Elasticsearch cluster you no longer have to run.
The pitch, reduced to subtractionPhilippe Noel and Ming Ying did not study the problem from a whiteboard. They ran into it. At their previous startup, Whist - a cloud-hybrid browser - they hit the Postgres search wall themselves and assumed it was a them problem. It was not. It was an everyone problem, and the workarounds were uniformly miserable.
Their bet, placed in late 2023, was contrarian in the way good infrastructure bets usually are: instead of building a better external search engine, build the search engine into Postgres. Make the index update transactionally with your writes. Keep the ACID guarantees. Let people write SQL. If Postgres is going to eat the database world - and it is - then the thing that's missing should be added to Postgres, not bolted alongside it.
Sets the thesis that search belongs in the database. Previously co-founded Whist, where the Postgres search problem first bit.
Leads the engineering of a production-grade search engine written in Rust and wired into Postgres internals.
They didn't build a better Elasticsearch. They argued you shouldn't need one.
On the contrarian betParadeDB is roughly 87% Rust, built on the Tantivy search library and Apache DataFusion, and connected to Postgres through the pgrx framework. Translated out of the acronyms: it takes battle-tested search and analytics engines and teaches Postgres to speak them natively. You install an extension; you keep your database.
Full-text search with BM25 relevance ranking, highlighting, tokenization, faceting, and filtering - all queryable through plain SQL.
Columnar storage and analytical queries - aggregations and faceted filtering - for OLAP-style workloads inside Postgres, powered by Apache DataFusion.
Search indexes update transactionally with your writes and ride the write-ahead log, so search never lags the source of truth.
Deploy on Amazon RDS, Google Cloud SQL, Azure Postgres, or self-managed - via the extension or prebuilt Docker images.
You write SQL. It returns ranked results. The distributed-systems homework is cancelled.
What the product feels like in practiceParadeDB launches as an open-source Postgres extension for full-text search. The GitHub stars start climbing fast.
Alibaba Cloud signs on as customer No. 1 - a Fortune 500 vote of confidence for a months-old project.
The company rebrands, retiring the dark-mode emerald look for a new identity.
A $12M Series A led by Craft Ventures, with Y Combinator participating, brings total funding to about $14M.
A team of ~10 ships ACID-consistent search and analytics into Postgres for Alibaba, Modern Treasury, Bilt Rewards, and TCDI.
Infrastructure doesn't get adopted because of a clever landing page. It gets adopted because someone tried it on a Friday and it didn't page them on Saturday. ParadeDB's traction reads like that kind of trust: more than 100,000 installs, nearly 8,900 GitHub stars, and a customer list that runs from a Fortune 500 cloud provider to fast-moving fintechs.
Bars scaled for readability, not to a shared axis - stars, installs, and dollars don't share a unit. Figures are approximate and drawn from public sources.
Named users include Alibaba, Modern Treasury, Bilt Rewards, UnifyGTM, and the legal-tech firm TCDI. The common thread isn't an industry - it's a moment. Each hit the point where Postgres-native search stopped being enough and the two-database tax came due.
A four-person team reached roughly $440K in revenue before the Series A. Lean is not the same as small.
On capital efficiencyThe mission is almost stubborn in its simplicity: make Postgres the only data store most companies need - for transactions, search, and analytics alike. It is a bet that the sprawl of the modern data stack is a phase, not a destiny, and that the winning move is consolidation rather than yet another specialized box with its own arrow pointing at it.
There's a worldview underneath it. As more software leans on AI, the data it reasons over has to be fresh and searchable - and the freshest copy of your data is the one already sitting in your primary database. Shipping it elsewhere to make it searchable is exactly the round trip ParadeDB wants to delete.
The freshest copy of your data is the one you didn't have to copy.
The mission, in one lineReturn to the engineer staring at the diagram. Two boxes, one arrow, a pipeline full of bugs. ParadeDB's whole argument is that the second box was never the point.
Erase Elasticsearch. Erase the arrow. What's left is one box - Postgres - that now ranks results, highlights matches, runs analytics, and stays consistent because the index and the data share the same transaction. The 3 a.m. page about a stale search index doesn't get fixed. It stops existing. That is a smaller diagram, and a quieter weekend, and for a growing list of companies it's already the new normal. The bet that search belongs in the database is no longer a hunch. It has a customer list.