Skip to main content
Ardent works with AWS RDS for PostgreSQL. This page covers only what’s specific to RDS — the full walkthrough is the Quickstart.
With the ardent-cli skill installed, a short ask is enough — the skill fetches this page and runs the checks:
Without the skill, paste the full directions:
RDS needs three things before preflight can pass:
1

Enable logical replication

Create or modify a parameter group for your RDS Postgres major version and set:
Apply the parameter group to your instance.
This takes effect only after a reboot. Plan a maintenance window.
Keep enough replication slots and WAL sender capacity for Ardent plus any existing replicas or CDC tools. Don’t lower values that other replication consumers rely on.
2

Allow network access

In the RDS console, open Databases > your instance > Connectivity & security and confirm the endpoint and port. Allow Ardent’s outbound IP to reach the instance on the Postgres port, usually 5432. Ask your Ardent contact for the current outbound IP if you don’t have it.
If your instance is private-only, use a BYOC environment and PrivateLink instead of allowing public inbound connections.
3

Grant the replication role

Connect as a role with rds_superuser privileges and grant RDS’s replication role to the user Ardent will connect as:
Per-database and per-schema grants may also be needed — preflight generates the exact SQL for those.
Your connection string looks like:
From here, continue with the Quickstart: run preflight, run the grant script if preflight prints one, then create the connector. Two RDS-specific notes:
  • If preflight says the source is a read replica, use the writer endpoint instead.
  • WAL retention: replication slots retain WAL while a consumer is behind. A very low retention limit can invalidate the slot under heavy writes or long transactions, forcing a connector rebuild. Leave enough headroom and watch long-running transactions.