Схема базы данных и команды DDL не реплицируются. Исходная схема может быть перенесена вручную с помощью pg_dump --schema-only. Последующие изменения схемы необходимо синхронизировать вручную. (Следует отметить, однако, что схемы не обязательно должны быть абсолютно идентичны на обеих сторонах.) Логическая репликация устойчива к изменениям определений схемы в работающей базе данных: если при изменении схемы на издателе поступающие на подписчик данные не соответствуют текущей схеме таблицы, процесс репликации будет завершаться с ошибкой до тех пор, пока схема не будет обновлена. Во многих случаях возникновения кратковременных ошибок можно избежать путем предварительного применения аддитивных изменений схемы на стороне подписчика.

Данные последовательностей не реплицируются. Данные в столбцах типа serial или identity, связанных с последовательностями, будут реплицироваться в составе таблицы, однако сама последовательность на стороне подписчика по-прежнему будет содержать начальное значение. Если база данных подписчика используется в режиме «только чтение», это обычно не создает проблем. Если, однако, планируется переключение или отработка отказа на базу данных подписчика, то значения последовательностей необходимо обновить до актуальных либо путем копирования текущих данных с издателя (например, с использованием pg_dump) или путем определения достаточно высокого значения на основе самих таблиц.

Репликация TRUNCATE команд поддерживается, однако при очистке групп таблиц, связанных внешними ключами, необходимо соблюдать осторожность. При репликации действия по очистке подписчик очистит ту же группу таблиц, которая была очищена на издателе, — либо указанную явно, либо собранную неявно с помощью CASCADE, за исключением таблиц, не входящих в подписку. Это будет работать корректно, если все затрагиваемые таблицы входят в одну и ту же подписку. Однако если некоторые таблицы, подлежащие очистке на стороне подписчика, имеют связи по внешнему ключу с таблицами, не входящими в ту же (или любую другую) подписку, выполнение действия по очистке на подписчике завершится ошибкой.

Большие объекты (см. Глава 4.2) не реплицируются. Единственным способом обхода данного ограничения является хранение данных в обычных таблицах.

Репликация поддерживается только для таблиц, включая секционированные таблицы. Попытки репликации других типов отношений, таких как представления, материализованные представления или сторонние таблицы, приведут к ошибке.

При репликации между секционированными таблицами процесс репликации по умолчанию инициируется из конечных секций на издателе, поэтому секции на издателе должны также существовать на стороне подписчика в качестве допустимых целевых таблиц. (Они могут быть как самими конечными секциями, так и подсекциями более низкого уровня или даже независимыми таблицами). В публикациях также может быть указано, что изменения должны реплицироваться с использованием идентификатора и схемы корневой секционированной таблицы вместо данных индивидуальных конечных секций, в которых эти изменения фактически возникают (см. publish_via_partition_root параметр CREATE PUBLICATION).

При использовании REPLICA IDENTITY FULL для опубликованных таблиц важно отметить, что UPDATE и DELETE операции не могут быть применены на стороне подписчиков, если таблицы содержат атрибуты с типами данных (такими как point или box), для которых отсутствует класс операторов по умолчанию для B-дерева (B-tree) или Hash. Тем не менее, данное ограничение можно обойти, обеспечив наличие в таблице первичного ключа или определенного для нее идентификатора реплики.