--- title: Logical replication improvements in Amazon RDS for... description: PostgreSQL 18 brings five notable improvements to logical replication, all available on Amazon RDS for PostgreSQL 18 and Aurora PostgreSQL. STORED generated... canonical: https://daily.dev/posts/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Logical replication improvements in Amazon RDS for PostgreSQL 18 | daily.dev og:description: PostgreSQL 18 brings five notable improvements to logical replication, all available on Amazon RDS for PostgreSQL 18 and Aurora PostgreSQL. STORED generated... og:url: https://daily.dev/posts/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop og:image: https://api.daily.dev/og/posts/FJk1ZtIoP.png og:image:alt: Logical replication improvements in Amazon RDS for PostgreSQL 18 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. # Logical replication improvements in Amazon RDS for PostgreSQL 18 **[AWS Database Blog](https://daily.dev/sources/aws-database-blog)** · 14 min read · 1 upvotes · 0 comments ## Summary PostgreSQL 18 brings five notable improvements to logical replication, all available on Amazon RDS for PostgreSQL 18 and Aurora PostgreSQL. STORED generated columns can now be included in the replication stream via the new `publish_generated_columns` publication parameter. Seven new conflict counters in `pg_stat_subscription_stats` (e.g., `confl_insert_exists`, `confl_update_missing`) replace the single opaque error count for easier diagnostics. Parallel streaming (`streaming = parallel`) is now the default for new subscriptions, reducing memory pressure and replication lag for large transactions. Two-phase commit can be toggled on a live subscription with `ALTER SUBSCRIPTION` without dropping and recreating it. Finally, `idle_replication_slot_timeout` automatically invalidates abandoned replication slots at checkpoint time, preventing unbounded WAL accumulation. The post walks through each feature with actual SQL and output on two RDS 18.3 instances. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I replicate a STORED generated column in PostgreSQL 18 logical replication? Set the publication parameter publish_generated_columns to 'stored' when creating the publication, which includes STORED generated columns in the replication stream as regular columns. On the subscriber, the corresponding column must be defined as a regular column, not GENERATED, or the apply process fails since PostgreSQL cannot write a received value into a generated column. Only STORED columns qualify; virtual generated columns have no physical storage and cannot be replicated. The default value 'none' preserves PostgreSQL 17 behavior of excluding generated columns. _Developers wiring up PostgreSQL replication pipelines can track version-specific gotchas like this on daily.dev._ ### What changed with the default streaming behavior for CREATE SUBSCRIPTION in PostgreSQL 18? PostgreSQL 18 changes the default from streaming = off to streaming = parallel, so large transactions begin replicating before they finish instead of being fully buffered in memory first. This reduces memory consumption that previously could reach several hundred MB to multiple GB for very large transactions, and it shortens replication lag. Up to 2 parallel apply workers per subscription are allowed by default, drawn from a pool of 4 logical replication workers, and no configuration changes are needed to get this on new subscriptions. _Teams tuning replication throughput can follow defaults-changing updates like this via daily.dev before they hit production surprises._ ### How can I automatically clean up idle PostgreSQL logical replication slots that a decommissioned subscriber left behind? Set the idle_replication_slot_timeout parameter, introduced in PostgreSQL 18, to a non-zero number of seconds; at the next checkpoint, any slot idle longer than that duration is invalidated and stops retaining WAL, freeing disk space on the publisher. The default value is 0, meaning the timeout is disabled. Invalidation happens at checkpoint time rather than instantly, so there can be a delay up to checkpoint_timeout, and a manual checkpoint can force immediate cleanup. On Amazon RDS the setting can be changed without rebooting the instance. _Operators chasing WAL bloat from abandoned replication slots can keep up with fixes like this through daily.dev._ ## Similar posts on daily.dev - [PostgreSQL 18 on Amazon Aurora and Amazon RDS: Security, monitoring, and developer enhancements](https://daily.dev/posts/postgresql-18-on-amazon-aurora-and-amazon-rds-security-monitoring-and-developer-enhancements-9ik7lifyc) · AWS Database Blog · 0 upvotes · 0 comments - [Amazon Aurora now supports PostgreSQL major version 18](https://daily.dev/posts/amazon-aurora-now-supports-postgresql-major-version-18-f2vatmgdl) · AWS · 5 upvotes · 0 comments - [Consolidating databases with Postgres logical replication](https://daily.dev/posts/consolidating-databases-with-postgres-logical-replication-2uvwobhja) · Planet PostgreSQL · 0 upvotes · 0 comments - [PostgreSQL 18 on Amazon Aurora and Amazon RDS: Performance enhancements](https://daily.dev/posts/postgresql-18-on-amazon-aurora-and-amazon-rds-performance-enhancements-lag8ehltp) · AWS Database Blog · 0 upvotes · 0 comments --- Tags: [#aws](https://daily.dev/tags/aws), [#backend](https://daily.dev/tags/backend), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop) ```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":"Logical replication improvements in Amazon RDS for PostgreSQL 18","url":"https://daily.dev/posts/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop"},"datePublished":"2026-07-07T16:48:01.049Z","dateModified":"2026-09-13T21:52:31.486Z","description":"PostgreSQL 18 brings five notable improvements to logical replication, all available on Amazon RDS for PostgreSQL 18 and Aurora PostgreSQL. STORED generated...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9d49a2c42b2cb48dea645e7b8126e203?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9d49a2c42b2cb48dea645e7b8126e203?_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/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"aws,backend,postgresql","timeRequired":"PT14M"} {"@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":"Logical replication improvements in Amazon RDS for PostgreSQL 18"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/logical-replication-improvements-in-amazon-rds-for-postgresql-18-fjk1ztiop#faq","mainEntity":[{"@type":"Question","name":"How do I replicate a STORED generated column in PostgreSQL 18 logical replication?","acceptedAnswer":{"@type":"Answer","text":"Set the publication parameter publish_generated_columns to 'stored' when creating the publication, which includes STORED generated columns in the replication stream as regular columns. On the subscriber, the corresponding column must be defined as a regular column, not GENERATED, or the apply process fails since PostgreSQL cannot write a received value into a generated column. Only STORED columns qualify; virtual generated columns have no physical storage and cannot be replicated. The default value 'none' preserves PostgreSQL 17 behavior of excluding generated columns. Developers wiring up PostgreSQL replication pipelines can track version-specific gotchas like this on daily.dev."}},{"@type":"Question","name":"What changed with the default streaming behavior for CREATE SUBSCRIPTION in PostgreSQL 18?","acceptedAnswer":{"@type":"Answer","text":"PostgreSQL 18 changes the default from streaming = off to streaming = parallel, so large transactions begin replicating before they finish instead of being fully buffered in memory first. This reduces memory consumption that previously could reach several hundred MB to multiple GB for very large transactions, and it shortens replication lag. Up to 2 parallel apply workers per subscription are allowed by default, drawn from a pool of 4 logical replication workers, and no configuration changes are needed to get this on new subscriptions. Teams tuning replication throughput can follow defaults-changing updates like this via daily.dev before they hit production surprises."}},{"@type":"Question","name":"How can I automatically clean up idle PostgreSQL logical replication slots that a decommissioned subscriber left behind?","acceptedAnswer":{"@type":"Answer","text":"Set the idle_replication_slot_timeout parameter, introduced in PostgreSQL 18, to a non-zero number of seconds; at the next checkpoint, any slot idle longer than that duration is invalidated and stops retaining WAL, freeing disk space on the publisher. The default value is 0, meaning the timeout is disabled. Invalidation happens at checkpoint time rather than instantly, so there can be a delay up to checkpoint_timeout, and a manual checkpoint can force immediate cleanup. On Amazon RDS the setting can be changed without rebooting the instance. Operators chasing WAL bloat from abandoned replication slots can keep up with fixes like this through daily.dev."}}]} ```