Because the first CDC sync never finishes and the slot is already exceeding

max_slot_wal_keep_size

, the problem is less about frequency and more about how much WAL is generated during that long‑running initial snapshot. From the docs and forum threads, there are a few concrete levers you can use on the Airbyte/Postgres side (without only relying on raising

max_slot_wal_keep_size

): 1. Shorten the initial snapshot window (fewer tables / staged loads) The initial CDC sync does a full snapshot of all selected tables and then starts streaming WAL. For very large datasets, that snapshot can take long enough that WAL for the slot grows past your 1 GB cap. [[Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#connector-limitations)] To reduce pressure: - Start with a smaller subset of tables (or the most critical ones). - Once those are synced and CDC is running, add more tables in additional connections or phases. 2. Make sure WAL isn’t being purged faster than Airbyte can read it If Postgres purges WAL needed by the slot during that long first run, Airbyte will fail and the slot can be invalidated. The docs recommend: - Increasing WAL retention (e.g.,

wal_keep_size

/ WAL retention period) so it’s longer than the time the initial sync takes, and - Running syncs frequently once the snapshot is done. [[CDC best practices](https://docs.airbyte.com/platform/understanding-airbyte/cdc-best-practices#database-level-cdc-configuration); [Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)] I understand you’re hesitant to increase

max_slot_wal_keep_size

, but for the initial load you may need a temporary bump (e.g., a few GB) so the first snapshot can complete, then you can lower it again once CDC is stable. 3. Use a heartbeat / high‑volume table so the slot advances cleanly With low or bursty write volume, Debezium/Airbyte can end up in a state where WAL accumulates but the slot’s

confirmed_flush_lsn

doesn’t advance, which keeps disk reserved and can hit your slot limit. [[WAL disk consumption](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#advanced-wal-disk-consumption-and-heartbeat-action-query); [Replication slot safe_wal_size](https://discuss.airbyte.io/t/3263)] Two options from the docs: - Write‑access option (recommended) - Create an

airbyte_heartbeat

table, add it to the publication, and configure the Debezium heartbeat query in the Postgres source so Airbyte periodically inserts into it. [[WAL disk consumption](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#advanced-wal-disk-consumption-and-heartbeat-action-query)] - Read‑only option - Add a naturally high‑churn table to the publication (even if you don’t sync it in Airbyte) so WAL moves forward and can be recycled. [[WAL disk consumption](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#advanced-wal-disk-consumption-and-heartbeat-action-query)] 4. If the slot is already invalidated, you must recreate it and reset the connection Once Postgres says the slot is invalid because it exceeded the reserved size, it can’t be reused. You’ll need to: - Drop and recreate the replication slot (and publication if needed), and - In Airbyte, Reset the connection so it performs a fresh snapshot and then CDC. [[Cloud SQL CDC setup](https://docs.airbyte.com/integrations/sources/postgres/cloud-sql-postgres#advanced-setup-using-cdc); [Postgres troubleshooting](https://docs.airbyte.com/integrations/sources/postgres/postgres-troubleshooting#troubleshooting)] Given that your first daily sync doesn’t terminate: 1. Temporarily increase

max_slot_wal_keep_size

and/or WAL retention enough to cover the initial snapshot duration. 2. Reset the connection and recreate the slot/publication. 3. Limit the initial sync to a smaller set of tables (or run multiple connections) so the snapshot can finish. 4. Configure a heartbeat (or add a high‑volume table to the publication) so the slot’s LSN advances and WAL can be recycled. If you share approximate DB size and write rate, you can then tune how much you actually need to raise

max_slot_wal_keep_size

for that first run.