peerdb is a free, open source data engineering & integration project written in Go and released under AGPL-3.0. It has 3,272 GitHub stars, 212 forks and 204 open issues, and was last pushed 8 hours ago. On this registry it ranks #18 of 39 tracked projects in Data Engineering & Integration, with 5 head-to-head comparisons available. It gained 2 stars over the last 3 tracked days.

What is peerdb?

What it is

PeerDB is a data integration project in the Postgres ecosystem. It lives in the Data & Analytics / Data Engineering & Integration category and focuses on streaming data from Postgres to data warehouses, queues, and storage engines. The project is built around Postgres-first ETL and change-data-capture workflows rather than a broad connector catalog.

The problem it addresses is moving large amounts of data from Postgres to downstream systems without building custom pipelines. The README says current data tools often prioritize many connectors and do not optimize for Postgres users who transfer data frequently. PeerDB supports log-based CDC, cursor-based timestamp or integer replication, and XMIN-based replication. The README states that PeerDB is 10x faster than existing tools.

Key capabilities

  • PeerDB replicates data from Postgres to data warehouses, queues, and storage engines.
  • The project uses log-based CDC as the recommended and actively maintained mirror type.
  • PeerDB supports cursor-based timestamp or integer replication and XMIN-based replication, although those mirror types are deprecated.
  • The tool handles native Postgres data types, including jsonb, arrays, and geospatial types.
  • PeerDB streams TOAST columns efficiently and supports schema changes.
  • The actively maintained destination paths are Postgres to ClickHouse, Postgres to ClickHouse Cloud, and Postgres to Postgres.
  • PeerDB stages PostgreSQL data in MinIO before loading it into ClickHouse.

Who uses it and how

  • Teams that run Postgres at the center of their data stack use PeerDB to move data to analytical or storage targets.
  • Users who need realtime Postgres replication use the CDC path, especially toward ClickHouse or another Postgres instance.
  • Operators run the stack with Docker Compose, including a Postgres catalog, Temporal, the PeerDB server, the flow API and workers, and the UI.
  • Users with ClickHouse outside Docker configure network access to MinIO and update AWS_ENDPOINT_URL_S3 so that both PeerDB and ClickHouse can reach MinIO.
  • Users connect to PeerDB with psql version 14.0 or later and query through the exposed port.

Getting started

The typical method is to clone the repository and run ./run-peerdb.sh with Docker and Docker Compose installed. For local development, users generate protobuf files with buf and run ./dev-peerdb.sh, then connect with psql using port 9900, host localhost, and password peerdb.

When to use it — and when not to

PeerDB fits self-hosted Postgres-to-ClickHouse, Postgres-to-ClickHouse Cloud, and Postgres-to-Postgres pipelines, especially when the team wants a Postgres-specific CDC path. It is not a good fit for deployments that require actively maintained Snowflake, BigQuery, ElasticSearch, Kafka, Azure Event Hubs, Google Pub/Sub, or S3 destination connectors, because those paths are deprecated, although BigQuery remains a supported source. Operators must also run and maintain the Docker Compose stack, a catalog database, Temporal, MinIO staging, and network access for external ClickHouse.

project readme (upstream, from github) — read inline
Frustratingly simple ETL for Postgres

Workflow Status ElV2 License Slack Community

PeerDB

At PeerDB, we are building a fast, simple and the most cost effective way to stream data from Postgres to Data Warehouses, Queues and Storage engines. If you are running Postgres at the heart of your data-stack and move data at scale from Postgres to any of the above targets, PeerDB can provide value.

We support different modes of streaming - log based (CDC), cursor based (timestamp or integer) and XMIN based. Performance wise, we are 10x faster than existing tools. Features wise, we support native Postgres features such as comprehensive set of data-types incl. jsonb/arrays/geospatial, efficiently streaming TOAST columns, schema changes and so on.

Mirror type deprecation notice: CDC is the recommended and actively-maintained mirror type. The Query Replication (QRep) and XMIN mirror types are deprecated and no longer actively maintained; they remain fully functional, and no code is currently being removed.

Connector deprecation notice: The Snowflake, BigQuery, ElasticSearch, Kafka (including Confluent and Redpanda variants), Azure Event Hubs, Google Pub/Sub, and S3 destination connectors are deprecated and no longer actively maintained. They remain fully functional in the current and all prior releases, and no code is currently being removed. The actively-maintained paths going forward are Postgres → ClickHouse, Postgres → ClickHouse Cloud, and Postgres → Postgres. This deprecation applies to the destination role only — BigQuery remains a supported source. See the connector status matrix and the deprecated connectors migration guide for how to pin to a release or fork the relevant code.

Get started

git clone [email protected]:PeerDB-io/peerdb.git
cd peerdb

# Run docker containers: postgres as catalog, temporal, PeerDB server, PeerDB flow API + workers, PeerDB UI
# Requires docker and docker-compose installed: https://docs.docker.com/engine/install/
bash ./run-peerdb.sh
# OR for local development, images will be built locally.
# Requires docker, docker-compose as well as the buf compiler for protobuf generation
# https://buf.build/docs/installation
bash ./generate-protos.sh
bash ./dev-peerdb.sh

# connect to peerdb and query away (Use psql version >=14.0)
psql "port=9900 host=localhost password=peerdb"

IMPORTANT: Ensuring ClickHouse Access to MinIO

If your ClickHouse DB runs outside Docker (e.g., on VMs or ClickHouse Cloud), it may not have access to MinIO, which is used by PeerDB internally to stage files before loading them. Ensure ClickHouse has network access to MinIO.

PeerDB stages PostgreSQL data in MinIO within the Docker stack. Since ClickHouse is outside Docker, it needs a resolvable hostname for MinIO.

Update docker-compose.yml and set AWS_ENDPOINT_URL_S3 to MinIO's accessible IP (from both PeerDB and ClickHouse):

AWS_ENDPOINT_URL_S3: http://172.31.26.57:9001 # Change this to IP/host which is accessible by both PeerDB and ClickHouse

Rerun Docker Compose to apply changes. On AWS/GCP/Azure, also ensure the security group allows inbound access to MinIO.

Follow this 5-minute Quickstart Guide to see PeerDB in action i.e. streaming data in real-time across stores.

Why PeerDB

Current data tools prioritize a wide range of connectors, often neglecting to optimize for Postgres users. This can be problematic for those storing large amounts of data in Postgres and frequently transferring it. As a result, many resort to building custom pipelines when existing tools don't meet their needs. We've developed this project to provide a straightforward and reliable solution specifically for Postgres.

Postgres-first Approach

PeerDB is an ETL/ELT tool built for PostgreSQL. We implement multiple Postgres native and infrastructural optimizations to provide a fast, reliable and a feature-rich experience for moving data in/out of PostgreSQL.

For performance - we can parallelize initial load for a large table, still ensuring consistency. Syncing 100s of GB reduces from days to minutes. Our architecture is designed for real-time syncs and implements multiple logical replication related optimizations (e.g., tuning Postgres configs, parallel reading of slot). This enables 10x faster Change Data Capture with data-freshness of a few 10s of seconds even at large throughputs (10k+ tps).

For reliability, we have mechanisms in place for fault tolerance - state management, automatic retries, handling idempotency and consistency and so on (). Configurable batching and parallelism prevent out of memory (OOMs) and crashes.

From a feature richness standpoint, we support efficient syncing of tables with large (TOAST) columns. We support multiple streaming modes - log based (CDC), cursor based (timestamp or integer) and XMIN based (the cursor-based / Query Replication and XMIN modes are deprecated; CDC is recommended). We provide rich data-type mapping and plan to support every possible type (incl. Custom types) that Postgres supports to the best extent possible on the target data-store.

Now available natively in ClickHouse Cloud (Generally Available)

PeerDB is now available natively in ClickHouse Cloud (Generally Available). Learn more about it here.

Postgres-compatible SQL interface to do ETL

The Postgres-compatible SQL interface for ETL is unique to PeerDB and enables you to operate in a language you are familiar with. You can do ETL the same way you work with your databases.

You can use Postgres’ ecosystem to manage your ETL —

  1. Client tools like pgAdmin, psql to run SQL commands.
  2. BI tools like Grafana, Tableau to visually monitor syncs and transforms.
  3. Database migration and versioning tools like Flyway to manage your ETL.
  4. Any language (e.g., Python, Go, Node.js) and Scheduler (Airflow) for development.
  5. And many more.

Status

We have expanded our connector ecosystem to support multiple source connectors beyond Postgres, including MySQL, MongoDB, BigQuery, and CockroachDB. You can check the status of connectors here.

Connector Direction (source/destination) Status
Postgres Source Actively maintained
MySQL Source Actively maintained
MongoDB Source Actively maintained
CockroachDB Source Actively maintained
BigQuery Source Actively maintained
ClickHouse Destination Actively maintained
ClickHouse Cloud Destination Actively maintained
Postgres Destination Actively maintained
S3 Destination Deprecated
Snowflake Destination Deprecated
BigQuery Destination Deprecated
ElasticSearch Destination Deprecated
Kafka Destination Deprecated
Redpanda Destination Deprecated
Confluent Destination Deprecated
Azure Event Hubs Destination Deprecated
Google Pub/Sub Destination Deprecated

Local End to End testing

You can run locally the same end-to-end tests that our CI uses to validate changes, enabling fast iteration cycles during development.

For example:

cd flow
go clean -cache
go test -v -run TestGenericCH_MySQL ./e2e/

Or local debugging sessions.

These tests require both PeerDB services, source and destination stores to be running. We provide a local environment with all the necessary services and dependencies to run these tests.

This is done through Tilt orchestrated Docker compose.

To get the environment up you first need to specify the shared environment variables for both the test and the test environment in your local .env file. You can use the provided .env.example as a template: cp .env.example .env .

If a .env file is present in the project root, tests will automatically load it. Any variable defined in .env can be overridden by user-provided environment variables.

:memo: In the template, services URLs are set to `host.docker.interna

readme truncated — read the full docs on github

Frequently asked questions

Is peerdb free to use?

peerdb is open source under the AGPL-3.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does peerdb do?

Fast, Simple and a cost effective tool to replicate data from Postgres to Data Warehouses, Queues and Storage

What is peerdb written in?

peerdb is primarily written in Go. Its source is publicly available at https://github.com/PeerDB-io/peerdb, and it has 3,272 GitHub stars.