Postgres logical replication copies a reporting replica's rows but leaves its schema and sequences behind

The tutorial version is accurate as far as it goes. According to the post, the standard walkthrough is CREATE PUBLICATION on the primary, CREATE SUBSCRIPTION on the replica, and data flowing a few seconds later ^[14]. None of the four gotchas appears in the getting-started guide ^[14].

The author wanted a replica that analysts query all day, on a different major version, with its own read-tuned indexes ^[15]. A physical standby can't be that replica. It copies the whole cluster at the WAL block level. It must run the same major version as the primary. Any extra reporting index has to exist on the primary as well ^[1]. Heavy analytical queries on a standby show up as replay lag ^[2].

Start with the DDL gap, because it fails quietly for the people using the replica. When a column is added on the primary, the post describes two outcomes. Depending on replica identity and column defaults, the subscriber either gets silent gaps in reporting data or its replication worker stops on a missing-column error, and nobody notices until a dashboard is empty ^[5]. For an added column, that error means the subscriber has to have the column before the primary starts sending rows that carry it ^[16]. The post's general rule is ordering. Each migration on a published table gets a subscriber step, applied before or in lockstep with the primary's migration depending on the direction of the change, and some teams script that step into their migration tooling ^[6]. "Treat DDL against replicated tables as a two-database transaction, even though Postgres will never enforce that for you," the author wrote ^[7].

Sequences cost nothing on a replica that only serves reads. They matter when someone writes to the replica for a one-off fix, or when the replica is promoted in a failover and nextval() hands back an id that already exists ^[9]. The author reports seeing duplicate key errors weeks after a nominally read-only replica started carrying other work ^[9]. The remedy is manual: sync sequence values as part of setup and again in every resync ^[10].

The initial sync is the gotcha most likely to get someone paged. Run against a live primary during business hours, it can cause visible slowdowns, according to the post ^[12]. The advice is to schedule initial syncs for the largest tables in low-traffic windows, publish tables incrementally rather than the whole schema at once, and monitor replication lag and source-side load while the copy runs ^[12]. The copy runs as a long transaction on the source that holds a snapshot, competes for I/O and can extend vacuum-related bloat ^[11].

The fourth gotcha is not described in the available text, which ends partway through the third. The three that are described are setup and runbook work, and a few-second demo exercises none of them ^[14]. For a replica that needs its own major version and its own indexes, I would still choose logical replication. The cost is a migration step, a sequence sync and a copy schedule, all written before go-live ^[6][10][12].