--- title: Migrate Amazon Aurora PostgreSQL across major versions... description: Standard Aurora PostgreSQL major-version upgrade paths (in-place upgrade, blue/green deployment) break active Debezium CDC replication slots, forcing... canonical: https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Migrate Amazon Aurora PostgreSQL across major versions with active Debezium CDC connectors using native logical replication | daily.dev og:description: Standard Aurora PostgreSQL major-version upgrade paths (in-place upgrade, blue/green deployment) break active Debezium CDC replication slots, forcing... og:url: https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt og:image: https://api.daily.dev/og/posts/Vp2MYL7Zt.png og:image:alt: Migrate Amazon Aurora PostgreSQL across major versions with active Debezium CDC connectors using native logical replication og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Migrate Amazon Aurora PostgreSQL across major versions with active Debezium CDC connectors using native logical replication **[AWS Database Blog](https://daily.dev/sources/aws-database-blog)** · 22 min read · 0 upvotes · 0 comments ## Summary Standard Aurora PostgreSQL major-version upgrade paths (in-place upgrade, blue/green deployment) break active Debezium CDC replication slots, forcing hours-long re-snapshots for downstream consumers. This walkthrough shows an alternative using native PostgreSQL logical replication to bridge a source cluster (PostgreSQL 14) and a target cluster (PostgreSQL 17), synchronizing data, then executing a brief cutover that disables the subscription, syncs sequences, creates a new Debezium slot on the target, and redirects the connector with snapshot.mode=never. In testing, the database-side cutover took about 2.21 seconds with zero duplicate or missed events. The post also details parameter group settings, network requirements, five failure scenarios (failover, connector stalls, oversized Kafka messages, DDL changes, long-running transactions), rollback procedures, post-migration monitoring signals, and how to scale the pattern via CDK/Step Functions automation. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do my Debezium connectors need a full re-snapshot after an Aurora PostgreSQL blue/green deployment upgrade? Blue/green deployments drop logical replication slots at switchover, so Debezium loses its position in the write-ahead log and must re-snapshot the entire database, which can take hours per cluster. In-place major version upgrades also interrupt active CDC consumers due to required downtime. An alternative is bridging a source and target cluster with native PostgreSQL logical replication and cutting the connector over directly, avoiding the re-snapshot entirely. _Anyone planning a CDC-safe Aurora upgrade can track detailed migration patterns like this via daily.dev._ ### How do I prevent duplicate Kafka events when cutting over a Debezium connector from one Postgres cluster to another? Pause the source connector and let it fully commit its offsets before starting the target connector; never run both simultaneously, even briefly, because both would process overlapping LSN ranges and produce duplicate events. Validate the source connector has consumed up to the current LSN before proceeding, since that commits a complete offset set to Kafka Connect's __connect_offsets topic. _Teams orchestrating CDC cutovers without data loss can follow step-by-step migration guides on daily.dev._ ### Why does my Debezium connector on Aurora PostgreSQL fail with RecordTooLargeException, and how do I fix it? Debezium serializes each changed row into a single Kafka record, and its JSON envelope adds overhead on top of raw column data, so rows approaching Kafka's default 1 MB max.request.size (1,048,576 bytes) can exceed the limit before the raw data does; testing found a ~1.05 MB row failed while ~1 MB rows succeeded. Fix it by raising max.message.bytes at the broker/topic level and max.request.size in the connector's producer overrides, then restarting the connector, since it cannot skip the oversized record. _Engineers debugging Kafka size-limit failures in CDC pipelines can find troubleshooting writeups on daily.dev._ ## Similar posts on daily.dev - [Implementing real-time change data capture with Debezium for Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL](https://daily.dev/posts/implementing-real-time-change-data-capture-with-debezium-for-amazon-aurora-postgresql-and-amazon-rds-wwimwgweo) · AWS Database Blog · 0 upvotes · 0 comments - [Automating RDS Postgres to Aurora Postgres Migration](https://daily.dev/posts/automating-rds-postgres-to-aurora-postgres-migration-fef7rzlgb) · Netflix TechBlog · 13 upvotes · 0 comments - [Netflix Automates RDS PostgreSQL to Aurora PostgreSQL Migration Across 400 Production Clusters](https://daily.dev/posts/netflix-automates-rds-postgresql-to-aurora-postgresql-migration-across-400-production-clusters-gz0lmzjax) · InfoQ · 47 upvotes · 0 comments - [Debezium in Production: PostgreSQL to Kafka to Iceberg CDC Patterns That Actually Work](https://daily.dev/posts/debezium-in-production-postgresql-to-kafka-to-iceberg-cdc-patterns-that-actually-work-43qqjunc0) · BigData Boutique blog · 3 upvotes · 0 comments --- Tags: [#aws](https://daily.dev/tags/aws), [#postgresql](https://daily.dev/tags/postgresql), [#kafka](https://daily.dev/tags/kafka), [#debezium](https://daily.dev/tags/debezium) [View this post on daily.dev](https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Migrate Amazon Aurora PostgreSQL across major versions with active Debezium CDC connectors using native logical replication","url":"https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt"},"datePublished":"2026-08-12T16:12:35.004Z","dateModified":"2026-08-12T16:13:05.028Z","description":"Standard Aurora PostgreSQL major-version upgrade paths (in-place upgrade, blue/green deployment) break active Debezium CDC replication slots, forcing...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/927fda0a25584a423a48b1dc9a2fd0c4?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/927fda0a25584a423a48b1dc9a2fd0c4?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"AWS Database Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"AWS Database Blog","logo":"https://media.daily.dev/image/upload/s--En-avd2a--/f_auto,q_auto/v1780213446/logos/aws-database-blog?_a=BAMAMiWQ0","url":"https://daily.dev/sources/aws-database-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"aws,postgresql,kafka,debezium","timeRequired":"PT22M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"AWS Database Blog","item":"https://daily.dev/sources/aws-database-blog"},{"@type":"ListItem","position":3,"name":"Migrate Amazon Aurora PostgreSQL across major versions with active Debezium CDC connectors using native logical replication"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/migrate-amazon-aurora-postgresql-across-major-versions-with-active-debezium-cdc-connectors-using-nat-vp2myl7zt#faq","mainEntity":[{"@type":"Question","name":"Why do my Debezium connectors need a full re-snapshot after an Aurora PostgreSQL blue/green deployment upgrade?","acceptedAnswer":{"@type":"Answer","text":"Blue/green deployments drop logical replication slots at switchover, so Debezium loses its position in the write-ahead log and must re-snapshot the entire database, which can take hours per cluster. In-place major version upgrades also interrupt active CDC consumers due to required downtime. An alternative is bridging a source and target cluster with native PostgreSQL logical replication and cutting the connector over directly, avoiding the re-snapshot entirely. Anyone planning a CDC-safe Aurora upgrade can track detailed migration patterns like this via daily.dev."}},{"@type":"Question","name":"How do I prevent duplicate Kafka events when cutting over a Debezium connector from one Postgres cluster to another?","acceptedAnswer":{"@type":"Answer","text":"Pause the source connector and let it fully commit its offsets before starting the target connector; never run both simultaneously, even briefly, because both would process overlapping LSN ranges and produce duplicate events. Validate the source connector has consumed up to the current LSN before proceeding, since that commits a complete offset set to Kafka Connect's __connect_offsets topic. Teams orchestrating CDC cutovers without data loss can follow step-by-step migration guides on daily.dev."}},{"@type":"Question","name":"Why does my Debezium connector on Aurora PostgreSQL fail with RecordTooLargeException, and how do I fix it?","acceptedAnswer":{"@type":"Answer","text":"Debezium serializes each changed row into a single Kafka record, and its JSON envelope adds overhead on top of raw column data, so rows approaching Kafka's default 1 MB max.request.size (1,048,576 bytes) can exceed the limit before the raw data does; testing found a ~1.05 MB row failed while ~1 MB rows succeeded. Fix it by raising max.message.bytes at the broker/topic level and max.request.size in the connector's producer overrides, then restarting the connector, since it cannot skip the oversized record. Engineers debugging Kafka size-limit failures in CDC pipelines can find troubleshooting writeups on daily.dev."}}]} ```