Source connector

PostgreSQL connector

PostgreSQL integration for databases, warehouses and BI tools

Self-managed PostgreSQL instances. Datrise captures PostgreSQL entities such as tables, rows, schemas, indexes, sequences and replication slots, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The PostgreSQL Logical Replication (pgoutput) + SQL wire protocol authenticates with username / password, incremental runs key on WAL LSN via a logical replication slot's confirmed_flush_lsn, and PostgreSQL caps calls at max_wal_senders (default 10) caps concurrent replication connections per cluster, and max_replication_slots (default 10) caps concurrent logical slots; both are self-hosted config limits, not a vendor-imposed API quota.

Of the 6 objects, 6 sync as upserts keyed on the primary key and 0 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `hp_postgres_tables`) with a schema derived from the PostgreSQL API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the PostgreSQL pipeline page, and join the waitlist to get the PostgreSQL connector with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What PostgreSQL data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
tables	hp_postgres_tables	Upsert by primary key, incremental on updated-at
rows	hp_postgres_rows	Upsert by primary key, incremental on updated-at
schemas	hp_postgres_schemas	Upsert by primary key, incremental on updated-at
indexes	hp_postgres_indexes	Upsert by primary key, incremental on updated-at
sequences	hp_postgres_sequences	Upsert by primary key, incremental on updated-at
replication slots	hp_postgres_replication_slots	Upsert by primary key, incremental on updated-at

PostgreSQL API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	PostgreSQL Logical Replication (pgoutput) + SQL wire protocol
Authentication	username / password — Standard libpq authentication (typically SCRAM-SHA-256 per pg_hba.conf) over a wire-protocol connection opened with `replication=database` to enter logical-decoding walsender mode.
Pagination	keyset — An initial snapshot is pulled via primary-key keyset batches (`WHERE pk > $last ORDER BY pk LIMIT n`); ongoing change capture then streams sequentially by WAL LSN rather than paging rows.
Rate limit	max_wal_senders (default 10) caps concurrent replication connections per cluster, and max_replication_slots (default 10) caps concurrent logical slots; both are self-hosted config limits, not a vendor-imposed API quota
Incremental cursor	WAL LSN via a logical replication slot's confirmed_flush_lsn — The slot's `restart_lsn` marks how much WAL PostgreSQL must retain for that consumer, so a connector that falls behind (or disconnects) causes WAL to accumulate on the source disk rather than being dropped.
Webhooks	No
Bulk export	Yes — COPY TO / pg_dump (full-table bulk unload for initial snapshot)
Deletes detectable	Yes — Logical replication emits DELETE events for tables with REPLICA IDENTITY DEFAULT (primary key) or FULL; a table with no primary key and default REPLICA IDENTITY falls back to NOTHING and cannot identify which row was deleted at all.

Official API reference

What bites when replicating PostgreSQL

A table with no primary key defaults to `REPLICA IDENTITY NOTHING`, which logs no old-row information at all, so UPDATE/DELETE events on it either fail to replicate or (with FULL) bloat WAL by logging every column on every change; either way it needs an explicit `ALTER TABLE ... REPLICA IDENTITY` before subscribing.
DDL is never replicated by logical decoding: an `ALTER TABLE ADD COLUMN` on the publisher requires a manual, coordinated change on the consumer side or the subscription breaks on the next matching row.
With `max_slot_wal_keep_size = -1` (the default), an inactive or disconnected replication slot causes PostgreSQL to retain WAL indefinitely in `pg_wal`, which can fill the source database's disk if a connector's consumer goes down for an extended period.
Sequences (e.g. SERIAL/IDENTITY generators) are not replicated by logical replication, only the values they produced in table rows, so a downstream replica cannot be safely promoted to accept new writes without re-syncing sequence state separately.

Compare this against every other documented API