Why ParadeDB?
There are many search engines in the world, but they are mostly built for static datasets and eventual consistency. ParadeDB is for users who want first-class search and analytics performance, but frequently update data and need consistency between their source and their indexes. ParadeDB may be a good fit for your stack if:- You frequently update the data you want to run search queries over
- Elasticsearch lag, shard loss, or stale indexes keep you up at night
- You spend more time babysitting ETL processes than doing things that matter
- You enjoy using Postgres, you hate using Elasticsearch, or something in between
- You have tried tsvector and the GIN index for Postgres text search, but lack of fuzzy matching, BM25 relevance scoring, advanced query types, etc. leads to low-quality results
- Analytical queries in Postgres (e.g.
COUNT,GROUP BY, etc.) hit timeouts - You value simplicity when designing systems
ParadeDB vs. Alternatives
People usually compare ParadeDB to two other types of systems: OLTP databases like vanilla Postgres and search engines like Elastic.| OLTP database | Search engine | ParadeDB | |
|---|---|---|---|
| Primary role | System of record | Search and retrieval engine | System of record and search/analytics engine |
| Examples | Postgres, MySQL | Elasticsearch, OpenSearch | |
| ACID guarantees | Full ACID compliance, read-after-write guarantees | No transactions, atomic only per-document, eventual consistency, durability not guaranteed until flush | Full ACID compliance, read-after-write guarantees |
| Update & delete support | Built for fast-changing data | Struggles with updates/deletes | Built for fast-changing data |
| Search features | Basic FTS (no BM25, weak ranking) | Rich search features (BM25, fuzzy matching, faceting, hybrid search) | Rich search features (BM25, fuzzy matching, faceting, hybrid search) |
| Analytics features | Not an analytical DB (no column store, batch processing, etc.) | Column store, batch processing, parallelization via sharding | Column store, batch processing, parallelization via Postgres parallel workers |
| Lag | None in a single cluster | At least network, ETL transformation, and indexing time | None in a single cluster |
| Operational complexity | Simple (single datastore) | Complex (ETL pipelines, managing multiple systems) | Simple (single datastore) |
| Scalability | Vertical scaling in a single node, horizontal scaling through Kubernetes | Horizontal scaling through sharding | Vertical scaling in a single node, horizontal scaling through Kubernetes |
| Language | SQL | Custom DSL | Standard SQL with custom search operators |
Production Readiness
As a company, ParadeDB is over two years old. ParadeDB launched in the Y Combinator (YC) S23 batch and has been validated in production since December 2023. ParadeDB Community, the open-source version of ParadeDB, has been deployed over 100,000 times in the past 12 months. ParadeDB Enterprise, the durable and production-hardened edition of ParadeDB, powers core search and analytics use cases at enterprises ranging from Fortune 500s to fast-growing startups. A few examples include:- Alibaba, the largest Asia-Pacific cloud provider, uses ParadeDB to power search inside their data warehouse. Case study available.
- Bilt Rewards1, a rent payments technology company that processed over $36B in payments in 2024.
- Modern Treasury1, a financial technology company that automates the full cycle of money movement.
- UnifyGTM1, one of the fastest-growing startups in AI sales automation.
- TCDI1, a giant in the legal software and litigation management space.