Track: ParadeDB (Postgres BM25 search + analytics) — activate alongside PostgreSQL/ArcadeDB adoption #57

New issue

Open

opened 2026-07-05 12:34:16 -07:00 by pyr0ball · 0 comments

pyr0ball commented

2026-07-05 12:34:16 -07:00

Owner

Source

https://github.com/paradedb/paradedb — AGPL-3.0 (Community), Enterprise license available

What it is

PostgreSQL extension delivering Elasticsearch-quality full-text search and OLAP
analytics directly inside Postgres — no separate search infrastructure needed.

Built on:

Tantivy (Rust) — full-text search: BM25 scoring, top-K, highlighting,
customizable tokenizers/filters
Apache DataFusion — analytics: columnar storage, bucket/metrics aggregations,
faceted search, JOINs
pgrx — Postgres/Rust extension bridge

Standard SQL interface. ORM integrations: Drizzle, Django, SQLAlchemy, Rails, EF Core.

Current CF fit: LOW (same constraint as noisia — Postgres-only)

CF's stack is predominantly SQLite (Peregrine, Kiwi, Snipe, Turnstone, cf-licensing).
No product currently runs PostgreSQL, so there's no existing attachment point.

Why this one is worth tracking (unlike pure chaos-testing tools)

ParadeDB solves a real, recurring problem: full-text search is currently handled
ad-hoc across products (SQLite FTS5 in Kiwi recipe search, similar likely patterns
in Peregrine job matching and Turnstone log search). None of these are BM25-ranked
or support faceted filtering natively.

Activation path

This becomes actionable if/when PostgreSQL enters the CF stack:

ArcadeDB adoption (turnstone#69, circuitforge-orch#88) — ArcadeDB speaks the
PostgreSQL wire protocol. If either lands on real Postgres (vs. ArcadeDB's own
engine), ParadeDB could sit alongside it for search-heavy workloads ArcadeDB's
own search model doesn't cover as deeply.
cf-licensing at scale — if SQLite → PostgreSQL migration happens for
concurrent multi-product license checks, ParadeDB could power search over
license/usage records for admin tooling.
Kiwi recipe search — if pantry/recipe search outgrows SQLite FTS5, this is
a natural upgrade path (BM25 relevance ranking, faceted dietary filters).
Peregrine job search — BM25-ranked job matching with faceted filters
(location, salary, remote) is a stronger match experience than current approach.

License constraint

AGPL-3.0 (Community edition) — same pattern as YOLO26, Focus Flow: restricts CF
cloud/paid tier SaaS use without either an Enterprise license purchase or
inference/query-only architecture that avoids redistributing modified ParadeDB code.
Local/free tier use is unaffected.

Priority

Backlog — revisit when any product's data layer migrates to PostgreSQL. Track
alongside the ArcadeDB tickets since they're the most likely trigger.

turnstone#69, circuitforge-orch#88 (ArcadeDB — PostgreSQL wire protocol)
roadmap#55 (noisia — same Postgres-only constraint, different problem class)

## Source https://github.com/paradedb/paradedb — AGPL-3.0 (Community), Enterprise license available ## What it is PostgreSQL extension delivering Elasticsearch-quality full-text search and OLAP analytics directly inside Postgres — no separate search infrastructure needed. Built on: - **Tantivy** (Rust) — full-text search: BM25 scoring, top-K, highlighting, customizable tokenizers/filters - **Apache DataFusion** — analytics: columnar storage, bucket/metrics aggregations, faceted search, JOINs - **pgrx** — Postgres/Rust extension bridge Standard SQL interface. ORM integrations: Drizzle, Django, SQLAlchemy, Rails, EF Core. ## Current CF fit: LOW (same constraint as noisia — Postgres-only) CF's stack is predominantly SQLite (Peregrine, Kiwi, Snipe, Turnstone, cf-licensing). No product currently runs PostgreSQL, so there's no existing attachment point. ## Why this one is worth tracking (unlike pure chaos-testing tools) ParadeDB solves a real, recurring problem: full-text search is currently handled ad-hoc across products (SQLite FTS5 in Kiwi recipe search, similar likely patterns in Peregrine job matching and Turnstone log search). None of these are BM25-ranked or support faceted filtering natively. ## Activation path This becomes actionable if/when PostgreSQL enters the CF stack: - **ArcadeDB adoption** (turnstone#69, circuitforge-orch#88) — ArcadeDB speaks the PostgreSQL wire protocol. If either lands on real Postgres (vs. ArcadeDB's own engine), ParadeDB could sit alongside it for search-heavy workloads ArcadeDB's own search model doesn't cover as deeply. - **cf-licensing at scale** — if SQLite → PostgreSQL migration happens for concurrent multi-product license checks, ParadeDB could power search over license/usage records for admin tooling. - **Kiwi recipe search** — if pantry/recipe search outgrows SQLite FTS5, this is a natural upgrade path (BM25 relevance ranking, faceted dietary filters). - **Peregrine job search** — BM25-ranked job matching with faceted filters (location, salary, remote) is a stronger match experience than current approach. ## License constraint AGPL-3.0 (Community edition) — same pattern as YOLO26, Focus Flow: restricts CF cloud/paid tier SaaS use without either an Enterprise license purchase or inference/query-only architecture that avoids redistributing modified ParadeDB code. Local/free tier use is unaffected. ## Priority Backlog — revisit when any product's data layer migrates to PostgreSQL. Track alongside the ArcadeDB tickets since they're the most likely trigger. ## Related - turnstone#69, circuitforge-orch#88 (ArcadeDB — PostgreSQL wire protocol) - roadmap#55 (noisia — same Postgres-only constraint, different problem class)