Create a dedicated Debezium user with the minimum privileges for logical replication, not a superuser. The Debezium PostgreSQL documentation says a superuser technically works but potentially exposes your data to unauthorized access, and recommends a dedicated replication user with specific privileges.
What the docs say
Debezium's PostgreSQL connector documentation has a Security section. To stream changes, the connector must operate with specific privileges. Giving the user superuser privileges is one way, but the docs say this potentially exposes your PostgreSQL data to unauthorized access, so create a dedicated replication user and grant it only what it needs.
The Setting up permissions procedure repeats the point: superusers have the needed REPLICATION and LOGIN roles by default, but do not give the Debezium user elevated privileges. Define a role with at least REPLICATION and LOGIN, and create a user with the minimum required.
Privileges by task
| Need | Documented requirement |
|---|---|
| Stream changes | REPLICATION and LOGIN on the connector user |
| Create the replication slot automatically | REPLICATION privilege; if the slot is absent, the connector creates it |
| Create a publication with the pgoutput plug-in | CREATE privilege on the database |
| Initial snapshot | SELECT on the captured tables |
| Managed service accounts that are not the master user | On Amazon RDS, the rds_replication role, granted by a superuser |
Replication is also limited by host: the docs note replication can be performed only for a configured number of hosts, which ties into the server's host based access rules. Restrict the connector user to the connector's address.
Controls to add
- Dedicated account. One user for Debezium, not shared with applications.
- Narrow SELECT. Grant SELECT only on the tables you capture. The snapshot needs it, so do not grant it database wide.
- Mind the publication mode. The docs say the default value of publication.autocreate.mode is all_tables, and if no publication is found the connector tries to create one for all tables in the database. With a restricted account that fails, and with a powerful one it publishes more than you meant. For the pgoutput plug-in they recommend filtered, or a publication created in advance by an administrator with the disabled mode.
- Pre-create the slot if you want tighter control. The docs say production environments can create the replication slot manually before starting the connector.
- Network rules. Allow the account to connect only from the Connect workers.
- Credentials. Keep the password out of the connector config; see Kafka Connect config providers.
- Review. Re-check the grants when you add tables or upgrade.
Why this one matters
A change data capture connector reads every row change in the tables it follows, including personal data. The change stream then lands in Kafka topics, which have their own access rules. So the database user is the first of two places where capture scope is decided, and the topic ACLs are the second.
Capture only the tables you need. Everything you add to the connector's include list becomes a stream someone must secure.
Quick check
Does Debezium need a superuser?
No. The docs recommend a dedicated replication user with the minimum required privileges, such as REPLICATION and LOGIN, rather than elevated privileges.
What does the pgoutput plug-in need to create a publication?
The database user must have the CREATE privilege on the database, per the Debezium docs. An administrator can create the publication instead.
Sources
- Debezium connector for PostgreSQL, Debezium documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
