#### Frustratingly simple ETL for Postgres
[](https://github.com/Peerdb-io/peerdb/actions/workflows/ci.yml)
[](https://github.com/PeerDB-io/peerdb/blob/main/LICENSE.md)
[](https://slack.peerdb.io)
### **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):
```yaml
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](https://docs.peerdb.io/quickstart#quickstart) 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 (
#### **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](https://docs.peerdb.io/sql/commands/supported-connectors).
| 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:
```bash
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](https://tilt.dev/) 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.internal`, which is the name for the default Docker gateway in Docker Desktop set-ups such as macOS and Windows. Using the default gateway address allows both test processes and services running inside Docker to access services on the host machine. In native Docker (Linux) this name is not resolved by default, you might replace it with the default gateway IP (e.g., `172.18.0.1`) or add a custom entry to your `/etc/hosts` file to resolve `host.docker.internal` to the appropriate IP address. e.g:
```bash
echo "172.18.0.1 host.docker.internal" | sudo tee -a /etc/hosts
```
Then you can just run:
```bash
./tilt.sh
```
And follow the status of the services and access logs through the Tilt UI at http://localhost:10352/. [Dozzle](https://dozzle.dev/) is also included at http://localhost:8118/, providing real-time container resource utilization metrics (CPU, memory) and log streaming for all running Docker containers.