Postgres

Overview

The Postgres connector reads changes straight from the write-ahead log, so workflows react to what happened in your database without polling. Each change arrives as a typed event with the table schema attached, and every event shows up in the trace of the run it started.

Teams use it to start invoice matching when a payment row lands, to sync account changes into Salesforce and to alert a channel when an order sits unpaid for too long.

Supported versions

• Postgres 12 to 17, self-hosted or managed

• Amazon RDS and Aurora, Google Cloud SQL, Azure Database, Supabase and Neon

• Connections over TLS, with optional SSH tunnel or AWS PrivateLink

How CDC works

Tessel creates a publication for the tables you choose and a logical replication slot that it reads continuously. Changes are decoded with pgoutput, checked against the schema and delivered in commit order. If Tessel pauses, the slot holds your place, so no change is skipped.

CREATE PUBLICATION tessel_pub
  FOR TABLE public.invoices, public.payments;

SELECT pg_create_logical_replication_slot(
  'tessel_slot', 'pgoutput');

CREATE PUBLICATION tessel_pub
  FOR TABLE public.invoices, public.payments;

SELECT pg_create_logical_replication_slot(
  'tessel_slot', 'pgoutput');

CREATE PUBLICATION tessel_pub
  FOR TABLE public.invoices, public.payments;

SELECT pg_create_logical_replication_slot(
  'tessel_slot', 'pgoutput');

Backfill

On first connect, Tessel can snapshot existing rows so a new workflow starts with full history. Snapshots run in batches of 10,000 rows and do not lock your tables.

Permissions needed

Create a dedicated role for Tessel. It needs replication and read access to the tables in the publication. Write access is only required if a workflow uses the insert, update or upsert actions.

• REPLICATION on the role, or rds_replication on RDS

• SELECT on every table in the publication

• INSERT and UPDATE only on tables you write back to