Logical replication currently has the following restrictions or missing functionality. These might be addressed in future releases.
The database schema and DDL commands are not replicated.
The initial schema can be copied by hand using
pg_dump --schema-only. Subsequent schema
changes would need to be kept in sync manually. (Note,
however, that there is no need for the schemas to be
absolutely the same on both sides.) Logical replication is
robust when schema definitions change in a live database:
When the schema is changed on the publisher and replicated
data starts arriving at the subscriber but does not fit
into the table schema, replication will error until the
schema is updated. In many cases, intermittent errors can
be avoided by applying additive schema changes to the
Sequence data is not replicated. The data in serial or
identity columns backed by sequences will of course be
replicated as part of the table, but the sequence itself
would still show the start value on the subscriber. If the
subscriber is used as a read-only database, then this
should typically not be a problem. If, however, some kind
of switchover or failover to the subscriber database is
intended, then the sequences would need to be updated to
the latest values, either by copying the current data from
the publisher (perhaps using
pg_dump) or by determining a sufficiently
high value from the tables themselves.
commands is supported, but some care must be taken when
truncating groups of tables connected by foreign keys. When
replicating a truncate action, the subscriber will truncate
the same group of tables that was truncated on the
publisher, either explicitly specified or implicitly
tables that are not part of the subscription. This will
work correctly if all affected tables are part of the same
subscription. But if some tables to be truncated on the
subscriber have foreign-key links to tables that are not
part of the same (or any) subscription, then the
application of the truncate action on the subscriber will
Large objects (see Chapter 35) are not replicated. There is no workaround for that, other than storing data in normal tables.
Replication is only possible from base tables to base tables. That is, the tables on the publication and on the subscription side must be normal tables, not views, materialized views, partition root tables, or foreign tables. In the case of partitions, you can therefore replicate a partition hierarchy one-to-one, but you cannot currently replicate to a differently partitioned setup. Attempts to replicate tables other than base tables will result in an error.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.