PostgreSQL 18 Logical Replication for Generated Columns: What Changed

PostgreSQL 18 removed a small but frustrating edge case in logical replication: stored generated columns can now be included in publications. That matters for teams that use generated columns to keep derived values close to the data model, then rely on logical replication for migrations, read models, analytics pipelines, or cross-system integrations.

The change does not mean every generated value should be replicated by default. It means the publisher finally has a controlled way to send stored generated values when the subscriber needs exactly the same derived representation. For managed PostgreSQL users, the practical question is how to test the feature without turning a clean schema shortcut into a replication surprise.

The problem PostgreSQL 18 solves

Before PostgreSQL 18, generated columns were not published through logical replication in the same straightforward way as ordinary columns. The PostgreSQL 18 release notes describe the new publish_generated_columns publication parameter and explain the old behavior directly: generated columns were not replicated, so the subscriber had to compute the values if possible. That was manageable when both sides were PostgreSQL clusters with the same schema, the same expression, and the same function behavior. It was harder when the subscriber was a downstream system that did not understand the expression or when a migration needed byte-for-byte consistency during cutover.

Stored generated columns are attractive because they make a derived value visible, type-checked, and queryable without asking application code to write it every time. A SaaS application might store a normalized email, a search key, a computed billing period, or a shard hint as a stored generated column. If that column also feeds an index, an export, or a subscriber, replication behavior becomes part of the production contract.

What changed in PostgreSQL 18

PostgreSQL 18 adds an explicit publication option: publish_generated_columns. The CREATE PUBLICATION documentation says stored generated columns can be replicated if publish_generated_columns is set to stored. It also notes an important default: when a publication omits a column list, it replicates all non-generated columns by default. In other words, generated columns do not become silently included everywhere just because the server was upgraded.

That distinction is useful. Existing logical replication setups should not suddenly receive extra columns after an upgrade unless the publication is changed. New publications can make the inclusion explicit, and column lists can include generated columns as well. The safest interpretation is simple: PostgreSQL 18 gives you a switch, not an automatic policy.

The feature is especially helpful for non-PostgreSQL subscribers and integration systems. If the downstream target does not have PostgreSQL generated column semantics, sending the stored value can be simpler than rebuilding the expression outside the database.

Why managed PostgreSQL teams should care

Logical replication often appears during the moments when operational risk is already high: major version upgrades, provider migrations, regional moves, zero-downtime rebuilds, or analytics exports that cannot block production traffic. Generated columns are easy to forget in those plans because application code usually treats them like normal readable columns.

The migration failure mode is subtle. Base rows replicate correctly, but the downstream representation is missing a derived column or computes it differently. That may not break ingestion immediately. It can show up later as a missing index path, a reporting mismatch, a uniqueness problem, or a cutover validation failure.

Managed PostgreSQL reduces the server maintenance burden, but it does not remove schema semantics from the migration. If you are moving from one managed PostgreSQL environment to another, check whether the provider supports the PostgreSQL version and logical replication options you intend to use. If you are using ArmorDB for the target side, pair this review with a normal migration rehearsal and the backup practices in /blog/postgresql-backups-restore-strategy so the rollback path is as real as the replication path.

A practical test plan

Start with schema inventory. Find generated columns with a catalog query such as select table_schema, table_name, column_name, generation_expression from information_schema.columns where is_generated <> 'NEVER';. Then classify each generated column by whether the subscriber needs the stored value, can recompute it, or should ignore it.

Next, create a staging publication that mirrors the production shape. If the target needs stored generated columns, test an explicit publication definition rather than relying on broad assumptions. The PostgreSQL documentation makes the setting visible in CREATE PUBLICATION, so keep it in infrastructure code or a migration runbook where reviewers can see the intent.

Then validate with rows that exercise the expression, not only happy-path rows. Generated columns often normalize text, combine nullable values, derive ranges, or depend on immutable functions. Insert and update rows that cover nulls, unusual characters, boundary timestamps, and realistic application data. Confirm that initial copy and subsequent changes produce the expected subscriber values.

Finally, test cutover behavior. Logical replication correctness is not only about whether one row appears. It is about whether indexes, constraints, application queries, BI exports, and consistency checks all agree during the final switchover. If you are also changing PostgreSQL major versions, keep extension versions, collations, and function definitions in the review because they can affect recomputation strategies.

Common mistakes

The first mistake is assuming this feature applies to virtual generated columns. PostgreSQL 18 introduced virtual generated columns as the default for generated columns, while logical replication support here is about stored generated columns. If the value is computed at read time rather than stored, there is no stored value to publish in the same way.

The second mistake is treating generated columns as harmless implementation details. Once a generated value participates in an index, an API response, a sync feed, or a reporting model, it is part of the contract. Replication plans should name it explicitly.

The third mistake is upgrading the publisher without testing subscriber compatibility. A subscriber that expects a narrower column set, uses a different schema migration order, or maps rows into another storage system may need changes before generated values are published.

Takeaway

PostgreSQL 18's generated-column replication support is a practical improvement for migrations and integrations, not a reason to publish every derived value automatically. Use it when the subscriber needs the publisher's stored generated value, document the publication setting, and rehearse with real schema and data. If the subscriber can safely recompute the value, that may still be the cleaner design.

For managed PostgreSQL teams, the key benefit is operational clarity. Generated columns no longer have to be a hidden exception in logical replication plans, but they still deserve the same review as indexes, constraints, connection strings, and backups.

Sources / further reading

• PostgreSQL 18 release notes — https://www.postgresql.org/docs/18/release-18.html
• PostgreSQL 18 CREATE PUBLICATION documentation — https://www.postgresql.org/docs/18/sql-createpublication.html
• PostgreSQL logical replication publications — https://www.postgresql.org/docs/18/logical-replication-publication.html
• PostgreSQL generated columns documentation — https://www.postgresql.org/docs/18/ddl-generated-columns.html
• PostgreSQL 18 release announcement — https://www.postgresql.org/about/news/postgresql-18-released-3142/

Practical takeaway

If your schema uses stored generated columns, include them in the logical replication checklist for every migration and integration. PostgreSQL 18 gives you an explicit way to publish those values; the production-safe move is to choose that behavior deliberately and validate it before cutover.