データベーススキーマおよびDDLコマンドはレプリケーションされません。 初期スキーマは、pg_dump --schema-onlyを使ってコピーすることができます。 以後のスキーマ変更の同期は手動で行ないます。 （なお、両者でスキーマは完全に同じである必要はないことに留意してください。） 稼働中のスキーマ定義変更に対して、論理レプリケーションは頑健です。 スキーマがパブリッシャー側で変更され、レプリケーションデータがサブスクライバー側に到着し始めたものの、データがテーブルスキーマに合致しない場合は、スキーマが変更されるまではレプリケーションはエラーとなります。 多くの場合、間欠的なエラーは、サブスクライバーに先に追加的なスキーマ変更を行うことで避けることができます。

シーケンスデータはレプリケーションされません。 シーケンスによって裏付けされたSERIAL型や識別列のデータは、もちろんテーブルの一部としてレプリケーションされます。 しかし、シーケンス自体は、サブスクライバーがスタートした時の値のままです。 サブスクライバーが読み取り専用のデータベースとして使われているなら、通常は問題になりません。 しかし、サブスクライバーのデータベースをスイッチオーバーやフェイルオーバーするつもりなら、パブリッシャーから現在のデータをコピーするか（おそらくpg_dumpを使います）、テーブル自身から十分に大きな値を決定し、シーケンスを最新の値に更新しなければなりません。

TRUNCATEコマンドのレプリケーションはサポートされますが、外部キーで結びついたテーブル群を削除する場合には注意が必要です。 削除処理をレプリケーションするとき、サブスクライバーはパブリッシャーで明示的に指定され削除された、もしくはCASCADEにより暗黙的に削除されたテーブル群から、サブスクリプションの一部ではないテーブルを除いたテーブル群を削除します。 この処理は、外部キーで関連付けられた全てのテーブルが同一のサブスクリプションの一部であれば、正常に動作します。 しかし、サブスクライバーで削除されるテーブルが同一のサブスクリプションの一部でないテーブルと外部キーで接続されていた場合、サブスクライバー上の削除処理は失敗します。

ラージオブジェクト（第35章参照）はレプリケーションされません。 通常のテーブルにデータを格納する以外に回避方法はありません。

レプリケーションは、パーティション化テーブルを含むテーブルでのみサポートされています。 ビュー、マテリアライズドビュー、外部テーブルのような、その他の種類のリレーションをレプリケーションしようとすると、エラーになります。

パーティション化テーブル間でレプリケーションする場合には、実際のレプリケーションは、デフォルトでは、パブリッシャー側の末端のパーティションから開始します。ですので、パブリッシャー側のパーティションがサブスクライバー側にも有効な対象テーブルとして存在していなければなりません。 (対象テーブルは、それ自身が末端のパーティションかもしれませんし、さらにサブパーティション化されているかもしれません。独立したテーブルであっても構いません。) パブリケーションは、変更が実際に開始された個々の末端のパーティションのIDとスキーマの代わりに、パーティション化されたルートのテーブルのIDとスキーマを使って指定することもできます(CREATE PUBLICATIONのpublish_via_partition_rootパラメータを参照してください)。