ParadeDB is an AGPL-3.0 PostgreSQL extension, written in Rust and distributed from the paradedb repository, that upgrades Postgres with full-text search, BM25 scoring, vector retrieval, and aggregations so application data and the search engine live in one database — intended for teams that would otherwise deploy and sync a separate search system.

What it is

ParadeDB is a PostgreSQL extension and the home of the pg_search extension. It adds a custom index to Postgres for fast full-text and vector search, BM25 scoring, filtering, and aggregations, so that query workloads which normally require a dedicated search cluster run inside the database the application already uses. The implementation integrates battle-tested Rust libraries inside Postgres: pgrx bridges Postgres and Rust, Tantivy powers full-text and vector search, and Apache DataFusion handles OLAP processing. The project contributes upstream wherever possible and documents its architecture separately.

The problem it solves is the second system. Teams typically keep application data in Postgres and push searchable or analytical copies into an external search engine, then maintain the pipeline that keeps the two in sync. ParadeDB removes that second system: there is nothing extra to deploy and nothing to sync. The topic list places it in hybrid transactional and analytical processing territory, covering full-text search, BM25, hybrid search, columnar storage, aggregations, analytics, OLAP, MPP, and distributed search, all inside PostgreSQL.

Key capabilities

• Full-text search through a custom Postgres index, documented under the full-text overview.
• Vector search, exposed alongside full-text search rather than as a separate service.
• BM25 scoring with Top K ranking and result highlighting.
• Hybrid search that combines full-text and vector retrieval.
• Tokenizers and token filters for controlling how text is analyzed.
• Filtering, aggregates, bucket and metrics aggregations, and facets.
• Columnar storage indexing for analytical and OLAP-style queries, with JOIN support.

Who uses it and how

• Application teams using Drizzle, Django, SQLAlchemy, Rails, or EF Core through the official ParadeDB integrations for those frameworks.
• Small teams deploying to Railway, Render, Fly.io, DigitalOcean, or Dokku, where a single Postgres instance has to cover both transactional and search workloads.
• AI agent and assistant workflows through Agent Skills, the MCP integration, and the Cursor plugin.
• Teams consolidating search and analytics into one Postgres to avoid operating and reconciling a second datastore.

Getting started

Local installation runs a single script that starts ParadeDB in a fresh Docker container and drops into a psql session: curl -fsSL https://paradedb.com/install.sh | sh. Deployment is covered by the hosting options documentation.

How it compares

No comparable or competing product is named in the facts for this entry, so ParadeDB stands alone in this registry. The only adjacent projects named are its own dependencies — pgrx, Tantivy, and Apache DataFusion — and its framework and platform integrations, none of which occupy the same slot as a Postgres extension providing search and analytics in one database.

When to use it — and when not to

Choose it when the goal is one Postgres covering application data, full-text search, vector retrieval, and aggregations, and when the AGPL-3.0 licence fits the deployment. Anyone embedding it in a proprietary product, or needing terms outside AGPL-3.0, should look at the commercial licensing and enterprise support route rather than assuming the open-source licence covers their case, and self-hosters still operate Postgres itself plus whichever deployment target they pick. The repository carries 193 open issues with recent activity, which signals active maintenance but also a substantial open backlog worth reviewing against specific requirements.

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