Scaling Real-Time Analytics From PostgreSQL

Stream every change from the Postgres WAL in about one second

Serve live dashboards and data APIs for thousands of concurrent users

Run multi-table joins, full-text search, and vector search in a single engine

Submit your product and service requirements,
our team will respond within 1 business day.

VeloDB syncs Postgres with a single CREATE JOB statement

Real-time sync

Sync Postgres to analytics with one SQL statement

Traditional change data capture chains Debezium, Kafka, and Flink together just to move rows from Postgres into an analytical engine. That is three systems to deploy, monitor, and scale for what is really a single job.

VeloDB replaces the entire pipeline with one CREATE JOB statement. It reads the Postgres write-ahead log directly, loads a full snapshot on the first run, and then streams every change after that. Schema updates propagate on their own, and new rows are queryable in about one second.

See how native PostgreSQL CDC works in Doris 4.1

What you get

~1s

Freshness from commit to query

One

SQL statement replaces the whole pipeline

VeloDB joins normalized tables at query time using MPP execution

Speed and concurrency

Fast multi-table joins at high concurrency

A Postgres read replica still stores rows on a single node, so each query reads whole rows and complex joins run one core at a time. Adding replicas raises cost without making any single query faster.

VeloDB stores the same tables in columns and runs every query in parallel across the cluster. A cost-based optimizer chooses the join strategy, runtime filters drop irrelevant rows before the join, and Merge-on-Write keeps reads fast as data changes. Postgres keeps handling transactions while VeloDB serves analytics at any level of concurrency.

See how JD.com serves 10,000 analytical queries per second

VeloDB progressive filtering: SQL → BM25 → vector similarity

Hybrid search

Hybrid search across SQL, full-text, and vector

pgvector adds similarity search to Postgres, but it shares the same CPU, memory, and disk as your transactions. At scale, vector scans compete with production queries, and there is no way to shrink the candidate set before the expensive step runs.

VeloDB runs the workload on its own engine and filters in stages. SQL constraints narrow the rows first, BM25 keyword scoring ranks what remains, and vector similarity runs last on the small subset that survives. Because the most expensive step touches the least data, relevance goes up while cost comes down.

Read about progressive filtering in Doris 4.0

What you get

3 to 1

Search systems collapsed into one engine

~1s

Hybrid query response at scale