PeerDB vs DBConvert Streams
PeerDB is a Postgres-first CDC tool that streams data from operational databases into analytical targets like Snowflake, BigQuery, and ClickHouse.
DBConvert Streams is an operational database migration and CDC tool with a built-in IDE that writes back to operational databases, files, and S3.
Quick answer
Choose by job
Choose PeerDB if
- Your destination is an analytics target — Snowflake, BigQuery, ClickHouse — or a Kafka-family stream.
- Your primary source is PostgreSQL and you want Postgres-native snapshot reconciliation at scale.
- Your stack already includes ClickHouse and you want the vendor-recommended ingestion path.
- Downstream analytics is the consumer of your CDC events, not another operational database.
Choose DBConvert Streams if
- Your destination is another operational database, files, or S3 — not an analytics warehouse.
- You need initial Load, ongoing CDC, and validation inside the same product.
- Your stack centers on MySQL/MariaDB, PostgreSQL, files, or S3.
- You want desktop + Docker self-hosted distribution, not a hosted-cloud option.
At a glance
Side-by-side facts
Where PeerDB wins
Ingest Postgres into Snowflake, BigQuery, or ClickHouse
Designed around Postgres → analytics — pipeline patterns and type handling analytics teams already expect.
Take the ClickHouse-recommended path for Postgres CDC
ClickHouse acquired PeerDB in 2024. For Postgres → ClickHouse Cloud, PeerDB is the vendor-recommended route.
Land changes in Kafka, PubSub, or Event Hubs as first-class targets
Kafka, Redpanda, PubSub, Azure Event Hubs, S3, and GCS are real CDC destinations — useful when CDC feeds event consumers downstream.
Snapshot wide Postgres tables without long lock windows
Multi-LSN snapshot strategy handles big initial loads — designed for Postgres replication at scale.
Run on your infrastructure or on the hosted cloud
Open-source self-hosted plus a hosted PeerDB Cloud option. No single deployment shape mandated.
Where DBConvert Streams wins
Write CDC back into an operational target, not a warehouse
Target is another live database, files, or S3 — the CDC pipeline ends in a usable operational endpoint, not an analytics layer.
Inspect data inside the same product that moves it
Browse schemas, run SQL, edit rows, inspect ER diagrams alongside the CDC stream. PeerDB has no IDE — you bring your own SQL client.
Validate the cutover with data, not just delivery
Compare row counts and sample content between source and target inside the same UI. PeerDB leaves validation to the analytics layer.
Run Load, CDC, and Compare from one workspace
Initial population, validation, and ongoing CDC are one workflow. PeerDB focuses on the stream; initial-load inspection is your stack.
Pick a deployment shape that matches the work
Desktop apps (Win/macOS/Linux), Docker, and a web UI — not cloud-only, not Docker-only.
Workflow
Replicate operational databases back to another database — not into a warehouse
- 1Install DBConvert Streams as a desktop app or Docker distribution.
- 2Connect source and target operational databases (e.g., PostgreSQL → MySQL, or PG → PG replica) in Data Explorer.
- 3Run Load mode for the initial population with table mapping and filters.
- 4Open the Compare tab and validate row counts and sample data on the target before turning on CDC.
- 5Switch to CDC mode and monitor throughput, lag, and run history in Stream Monitor.
PeerDB ships Postgres changes into an analytics target like ClickHouse or Snowflake. DBConvert Streams writes back to another operational database — with the IDE and validation alongside.
Also supported
The same workflow runs for other source/target combinations:
- PostgreSQL → MySQL/MariaDB (cross-engine operational replication)
- MySQL/MariaDB → PostgreSQL (reverse, operational)
- MySQL/MariaDB ↔ MySQL/MariaDB (homogeneous operational)
- PostgreSQL ↔ PostgreSQL (homogeneous operational)
- MySQL/PostgreSQL → S3 / files (archival or downstream pipelines, not analytics warehouse)
- Files / S3 → MySQL or PostgreSQL (operational ingest)
FAQ
Frequently asked questions
Is DBConvert Streams a PeerDB replacement?
Different destinations, different jobs.
- PeerDB — Streams Postgres (and MySQL/MongoDB) changes into analytics targets — Snowflake, BigQuery, ClickHouse — and event streams like Kafka or PubSub.
- DBConvert Streams — Writes changes back to another operational database (MySQL/MariaDB, PostgreSQL), files, or S3 — with a built-in IDE and source/target comparison.
For Postgres → ClickHouse / Snowflake / BigQuery, PeerDB. For operational DB ↔ DB and DB ↔ files/S3 moves, DBConvert Streams.
Does PeerDB only support PostgreSQL as a source?
No. PeerDB supports PostgreSQL (primary), MySQL, and MongoDB as sources. The marketing and documentation center on Postgres CDC into analytics targets, but MySQL and MongoDB are real first-party sources.
Does DBConvert Streams support ClickHouse, BigQuery, or Snowflake as targets?
Not as analytics targets today. Snowflake is on the roadmap (coming soon). BigQuery and ClickHouse are not currently supported. If your destination is an analytics warehouse or stream, PeerDB is the better fit. DBConvert Streams targets operational databases, files, and S3.
Which is better for Postgres-to-Postgres replication?
It depends on where the target lives and what shape it has.
- PeerDB — Strong for Postgres → Postgres when the target is part of an analytics pipeline or you specifically want PeerDB's multi-LSN snapshot reconciliation.
- DBConvert Streams — Strong for operational Postgres → Postgres with a built-in IDE, Load + CDC + Compare in one workflow.
Is PeerDB part of ClickHouse now?
Yes. ClickHouse acquired PeerDB in 2024. PeerDB is still developed and offered, and is the recommended ingestion path for Postgres → ClickHouse Cloud. The open-source self-hosted distribution remains available.
When should I not use DBConvert Streams?
When your destination is an analytics warehouse (Snowflake before release, BigQuery, ClickHouse) or a streaming platform (Kafka, Redpanda, PubSub, Event Hubs). In those cases PeerDB is a better fit. Also when you need PeerDB-specific multi-LSN snapshot reconciliation for very large Postgres tables.
Related comparisons
