資料庫模式和 DDL 命令不會被複制。初始模式可以透過手動使用 pg_dump --schema-only 命令進行復制。後續的模式更改需要手動保持同步。（但請注意，兩邊的模式不必完全相同。）當現場資料庫的模式發生更改時，邏輯複製是健壯的：當釋出伺服器上的模式發生更改，並且複製的資料開始到達訂閱伺服器但與表模式不匹配時，複製將出錯，直到模式更新。在許多情況下，透過先在訂閱伺服器上應用增量模式更改，可以避免間歇性錯誤。

序列資料不會被複制。由序列支援的 serial 或 identity 列中的資料當然會作為表的一部分被複制，但序列本身在訂閱伺服器上仍將顯示起始值。如果訂閱伺服器用作只讀資料庫，那麼這通常不成問題。但是，如果打算進行某種切換或故障轉移到訂閱伺服器資料庫，那麼需要透過從釋出伺服器複製當前資料（可能使用 pg_dump）或從表本身確定一個足夠大的值來更新序列到最新值。

支援複製 TRUNCATE 命令，但截斷由外部索引鍵連線的表組時需要格外小心。複製截斷操作時，訂閱伺服器將截斷在釋出伺服器上被截斷的同一組表，這些表要麼是顯式指定的，要麼是透過 CASCADE 隱式收集的，但不包括不屬於訂閱的表。如果所有受影響的表都屬於同一個訂閱，這將正常工作。但是，如果訂閱伺服器上要截斷的某些表與不屬於同一訂閱（或任何訂閱）的表存在外部索引鍵連結，那麼在訂閱伺服器上應用截斷操作將失敗。

大型物件（請參閱 第 33 章）不會被複制。除了將資料儲存在普通表中，沒有其他解決方法。

複製僅支援表，包括分割槽表。嘗試複製其他型別的關係，如檢視、物化檢視或外部表，將導致錯誤。

在複製分割槽表之間時，預設情況下，實際複製源自發布伺服器上的葉子分割槽，因此釋出伺服器上的分割槽也必須存在於訂閱伺服器上作為有效的目標表。（它們可以是葉子分割槽本身，也可以進一步分割槽，甚至可以是獨立表。）釋出也可以指定使用分割槽根表的標識和模式來複制更改，而不是更改實際源自的各個葉子分割槽的標識和模式（請參閱 CREATE PUBLICATION 的 publish_via_partition_root 引數）。

在使用釋出表上的 REPLICA IDENTITY FULL 時，重要的是要注意，如果表包含資料型別（如 point 或 box）沒有 B-tree 或 Hash 預設運算子類的屬性，那麼 UPDATE 和 DELETE 操作將無法應用於訂閱伺服器。但是，透過確保表具有主鍵或副本標識為其定義，可以克服此限制。