PostgreSQL

PostgreSQL sources are read with logical replication: Fabric creates a replication slot, decodes the write-ahead log, and streams every insert, update, and delete. It is log-based CDC — no polling, no triggers, and no added load on your queries.

Supported deployments

The same connector serves self-hosted PostgreSQL, Amazon RDS, Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon, Timescale Cloud, and AlloyDB for PostgreSQL. Two managed differences are called out below: RDS and Aurora use the rds_replication group role rather than rolreplication, and Cloud SQL and Azure take a direct REPLICATION grant. Supabase and Neon must be reached on their direct endpoint — a connection-pooler endpoint does not carry logical replication.

Prerequisites

Server settings

• wal_level=logical — required. Logical decoding is refused otherwise. This is a restart-level setting.
• max_replication_slots — must have a free slot (existing logical slots plus one).
• max_wal_senders — at least 1.

A replication login

The login needs the REPLICATION attribute and read access to the tables being replicated:

CREATE ROLE fabric_cdc LOGIN PASSWORD '...' REPLICATION;
GRANT CONNECT ON DATABASE mydb TO fabric_cdc;
GRANT USAGE ON SCHEMA public TO fabric_cdc;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO fabric_cdc;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO fabric_cdc;

On Amazon RDS and Aurora the master user never has rolreplication; membership in the rds_replication group role works instead, and Fabric accepts it. On Azure Database for PostgreSQL and Cloud SQL, grant REPLICATION directly on the role.

Publication and heartbeat

With the default pgoutput plugin, Fabric reads the publication dbz_publication, and creates it FOR ALL TABLES if it does not exist. PostgreSQL allows that only for a superuser, so for any other login create the publication yourself first.

Fabric also keeps a heartbeat row so an idle source's slot still advances. If the login cannot create tables, pre-create it and let the login write to it:

CREATE TABLE IF NOT EXISTS public.heartbeat (
  id INTEGER PRIMARY KEY,
  last_update TIMESTAMPTZ NOT NULL
);
GRANT SELECT, INSERT, UPDATE ON public.heartbeat TO fabric_cdc;

The least-privilege guide has the full setup for a login with no superuser or CREATE rights, including a publication limited to the tables you sync.

Network

The Fabric runner must reach host:port over TCP, and pg_hba.conf must allow that login to connect — including a replication entry. The login also needs CONNECT on the postgres maintenance database, which the Test connection button uses to list databases.

Connection fields

The shared snapshot and commit fields apply on top of these — see the source overview.

How it replicates

• The initial snapshot is chunked by a single-column primary key (or a single-column NOT NULL unique column). A table with no safe key falls back to one unchunked pass. With parallel snapshot workers above 1, disjoint sets of tables are scanned over separate connections.
• The WAL position is captured before the first snapshot row, so a crash mid-snapshot resumes under the same mark instead of skipping changes.
• The replication slot is the durable resume position. It is kept when a runner stops; only Reset Pipeline drops it.

Gotchas