paradedb/paradedb

Postgres for Search and Analytics

Summary

ParadeDB is a Postgres extension written in Rust that adds full-text search, vector search, and analytical aggregations to standard PostgreSQL, keeping application data and search in one database. It is the home of the pg_search extension and combines BM25 scoring, hybrid search, and columnar aggregations behind ordinary SQL.

What it is useful for

Engineers can reach for ParadeDB when they need search and analytics features without standing up a separate engine like Elasticsearch or a dedicated vector database. According to the README, it supports BM25-based full-text search with highlighting and tokenizers, vector search for embeddings, and hybrid search that combines the two. It also exposes columnar storage, facets, and bucket and metric aggregations for OLAP-style queries, all joinable against regular application tables.

The project is built on three Rust libraries: pgrx to bridge Postgres and Rust, Tantivy for full-text and vector indexing, and Apache DataFusion for OLAP processing. Because everything runs as a Postgres extension, you keep ACID transactions and standard SQL rather than managing a second data store and its eventual consistency.

How engineers can use it

The documented local setup uses a Docker-based installer:

curl -fsSL https://paradedb.com/install.sh | sh

For production, the README points to ParadeDB Cloud (managed) and self-hosted deployment guides, with platform notes for Railway, Render, Fly.io, Dokku, and DigitalOcean. There are ORM integrations for Drizzle, Django, SQLAlchemy, Rails, and EF Core, plus AI-agent tooling such as an MCP integration and a Cursor plugin.

Once running, you interact with it through SQL by creating search indexes, running BM25-scored queries, and combining vector similarity with aggregates. The community edition is licensed under AGPL-3.0, while ParadeDB Enterprise is commercially licensed and bundled with the managed cloud offering. The README does not publish performance benchmarks, so you should validate query latency and index build times against your own data and consult the changelog for current capabilities before relying on specific limits.