When PostgreSQL streaming vs logical replication fits your workload
Choose physical streaming replication when you need a standby that can take over the whole cluster. Streaming replication copies exact block addresses and bytes, so the standby is a byte-for-byte image of the primary. Choose logical replication when you need to copy a table subset, consolidate several databases, move data between PostgreSQL major versions, or move it between platforms such as Linux and Windows. The PostgreSQL 18 documentation describes logical replication as working from replication identity, usually the primary key, which is why it can select a subset of objects while streaming cannot. Your first decision is which of those two jobs the copy has to do.
The two methods are often used together. A common pattern for a major upgrade is to keep a streaming standby for high availability on the current version while a logical replica on the new major version receives the changes, then cut over with a short write freeze. Neither method replaces the other for failover. PostgreSQL does not detect a primary failure or promote a standby on its own, so either way you need an external tool such as Patroni or CloudNativePG to decide when to promote. A logical subscriber also does not carry the schema, so a failover design built only on logical replication will not give you a ready-to-serve standby.
Licensing does not separate the two. PostgreSQL is released under the PostgreSQL License, a permissive license similar to the BSD and MIT licenses, and both replication methods ship in the same server with no paid tier. Your cost differences come from operating effort, not from licensing. Before you commit, confirm with your own platform team which replication features your managed or packaged distribution exposes and which major versions you must support, and check the current support windows on the PostgreSQL versioning policy page.
Streaming and logical replication across the factors that decide the choice
This table compares physical streaming replication and logical replication across the factors that decide which one fits a given PostgreSQL job. Read each row against your own requirement: if you need a full hot standby for failover, the streaming column answers it, and if you need a subset of tables or a different major version, the logical column does. The main takeaway is that the two methods solve different problems and are often used together during a migration.
| Factor | Physical streaming replication | Logical replication |
|---|---|---|
| Replication unit | Exact disk blocks, copied byte by byte at the block address level | Table changes identified by replication identity, usually the primary key |
| Target scope | Whole cluster, so every database and table is copied | Selected tables, including partitioned tables, chosen by publication |
| Cross-version support | Standby runs the same major version as the primary | Works between different PostgreSQL major versions, which supports major upgrades |
| Cross-platform support | Same architecture and binary layout as the primary | Documented for replication between platforms such as Linux and Windows |
| Read-only standby use | Hot standby serves read-only queries on the replica | Subscriber is a normal writable database, so reads and writes depend on your design |
| Synchronous commit support | Supported, where a commit waits for standbys to confirm | Changes are applied asynchronously on the subscriber per the replication documentation |
| Failover behavior | Standby can be promoted, but PostgreSQL does not detect primary failure, so external tools are required | Not a failover mechanism on its own; switching writes to the subscriber is a manual or scripted step |
| What it leaves out | Nothing at the cluster level, since the whole cluster is copied | Schema and DDL, sequence data and large objects must be handled separately |
How byte-level and row-level replication differ in practice
Physical streaming replication copies exact block addresses byte by byte, so a standby is an identical image of the primary. That is why it suits high availability: the standby can take over with the same data layout, indexes and cluster state, and it must run the same major PostgreSQL version as the primary. You cannot point a physical standby at PostgreSQL 17 while the primary runs 18, and you cannot use it to copy only three tables. Confirm before you design anything that a standby is a whole-cluster copy, and check that your failover target is built from the same major version and platform as the source.
Logical replication works at the row level. It decodes changes based on each table's replication identity, usually its primary key, and sends those changes to a subscriber. Because the subscriber receives row changes rather than blocks, you can replicate a subset of tables, move data between different major versions, or move it between platforms such as Linux and Windows. The PostgreSQL 18 documentation lists these uses, and the logical replication restrictions page is the next read before you commit. Tables without a primary key or replica identity need a decision on how their updates and deletes will be identified.
Neither method detects a failed primary on its own. PostgreSQL does not provide the software to notice a primary failure and notify the standby, so automatic failover needs external tools whichever replication method you choose. Plan that tooling, its fencing behavior and its promotion steps as a separate design item, and test a failover in a non-production environment. Physical standbys are the usual base for that tooling, while a logical subscriber is normally a migration or distribution target, so do not assume a logical subscriber can take over the primary role without an explicit cutover procedure.
What logical replication does not carry: DDL, sequences and large objects
Logical replication copies row changes for selected tables, but it leaves several categories of database state behind. Each gap below changes what a cutover must include, and each one has to be copied, scripted or verified by the team before traffic moves to the new server.
Schema and DDL commands
Logical replication does not replicate the database schema or DDL commands. A CREATE TABLE, ALTER TABLE or index change made on the publisher after the subscription starts does not reach the subscriber, so the replicated rows can stop matching the target structure. Before cutover, export the schema from the source with a schema-only dump, load it on the target, and confirm both sides match. Freeze DDL during the migration window or track every schema change in a separate deployment step.
Sequence data
Sequence values are not replicated, so the current value of a serial, identity or nextval() sequence on the subscriber stays at its initial state. If the application inserts rows on the new primary without resynchronizing sequences, primary key collisions or duplicate business identifiers can follow. The cutover runbook should include a step that reads each sequence on the publisher and sets the matching value on the subscriber after writes stop, and a check that the new value is higher than the largest key in each table.
Large objects
Large objects stored through the large object interface are not replicated, so files or blobs kept there are absent on the subscriber. Applications that store data as bytea columns are not affected, since those values live in ordinary table rows. Inventory the database for large object references before choosing this method. If they exist, plan a separate export and import of the large object store, verify object counts and sizes on both sides, and test that the application still reads them after cutover.
Only tables are replicated
Logical replication carries tables, including partitioned tables, and nothing else. Views, materialized views, functions, triggers, and other object types are outside the replication stream and must be created on the subscriber by other means. A partitioned table is replicated as a table, so the team must confirm that the partition layout on the subscriber matches what the application expects. Any object that the application needs to run must be listed in the migration inventory and verified on the target.
Which method to choose for each scenario
Physical streaming replication is the default for a high availability standby. It copies the cluster at the block level, so the standby is an exact image of the primary, including everything that logical replication skips. That makes it the right base for failover, where you need the whole cluster, not a selection of tables. PostgreSQL supports synchronous and asynchronous streaming, and a standby can be promoted to take over. Logical replication is the wrong tool for this job because it carries only table data and leaves behind schema changes, sequences and large objects.
- Whole-cluster copy: Streaming replication carries every database and all schema changes, which is what a failover target needs.
- Synchronous commits: Choose synchronous streaming when a commit must wait for a standby, and accept the latency that follows.
- Failover tooling: PostgreSQL does not detect a primary failure on its own, so plan for an external failover manager such as Patroni or CloudNativePG.
- Logical as a supplement: Logical replication can run beside streaming for specific subsets, but it does not replace the standby.
- Same major version: Standbys must run the same major version as the primary, so the standby and primary upgrade together.
Confirm with your database team which failover manager, replication mode and recovery time target you will use before you pick a method.
A hot standby serves read-only queries while it replays changes from the primary. This suits reporting queries, dashboards and read-heavy application paths that tolerate a small lag. Streaming replication fits because the standby mirrors the full cluster and answers queries against the same data as the primary. Logical replication can also feed a reporting database, but you then maintain a second schema, decide which tables to include and handle the write path separately.
- Read-only replicas: Hot standbys accept read queries against the complete dataset without any schema work.
- Lag tolerance: Asynchronous streaming gives the lowest impact on the primary, but reads may trail the latest commit.
- Reporting with different indexes: If the reporting workload needs extra indexes or tables that the primary does not carry, logical replication to a separate database is the better fit.
- Subset reads: When only a few tables are read at scale, a logical subscriber holds just those tables and can be sized for them.
- Application behavior: Check that read-only transactions and session settings work on the standby before you route traffic to it.
Test your read queries against the standby under peak load, and confirm the replication lag your application can accept.
Logical replication is designed for this case. It publishes changes for selected tables and sends them to a subscriber that can hold a different set of objects. Because it works from replication identity, usually a primary key, the subscriber does not need to match the publisher's physical layout. Physical streaming cannot do this, since it copies every block of the cluster. Use logical replication when the destination needs only part of the data, such as a regional service that reads a few reference tables.
- Table-level selection: Publications choose tables, and PostgreSQL 18 replicates only tables, including partitioned tables.
- Primary key requirement: Tables need a replication identity, usually a primary key, to receive updates and deletes correctly.
- Schema ownership: The schema is not copied, so the subscriber's tables must be created in advance and kept in step with the publisher.
- Sequences excluded: Sequence values do not replicate, so a subscriber that generates keys needs a separate plan.
- Physical copy case: If you need the full cluster for failover, a subset copy does not replace streaming replication.
Ask the subscriber team which tables, keys and schema changes they own, and who will apply DDL on each side.
Consolidation means merging the data from several source databases into one target. Logical replication can do this because each subscription copies selected tables from one publisher into the target, and several publishers can feed the same database. Streaming replication cannot merge databases, because a standby must be a byte-level copy of exactly one cluster. This makes logical replication the only option in PostgreSQL for combining sources, though it brings conflict and schema management work that a physical copy avoids.
- Multiple publishers: Several subscriptions can feed one target, one per source database.
- Name and key collisions: Source tables that share names or key ranges need renaming or key design before they can share a target.
- Schema alignment: Each source's schema must be created and maintained in the target, since DDL is not carried across.
- Conflict handling: Plan how duplicate or conflicting writes are resolved before cutover.
- Single cluster case: If you only need one database kept highly available, streaming replication remains simpler.
Write down the key scheme, schema owner and conflict rule for each source before you begin the merge.
For a major upgrade, the choice is between pg_dumpall with restore, pg_upgrade, and logical replication. Logical replication works across major versions, so you can build a newer cluster, copy the data while the old one stays live, and cut traffic over after the subscriber catches up. The PostgreSQL documentation describes this approach as allowing major upgrades with only several seconds of downtime, though actual downtime depends on your sequences, DDL and cutover process. Pg_upgrade is often simpler when a short outage is acceptable, because it converts the data directory in place.
- Replication-based cutover: Logical replication keeps the old primary serving while the new version catches up.
- Sequence handling: Sequences do not replicate, so set their values on the new cluster during cutover.
- DDL freeze: Schema changes during the window must be avoided or applied to both sides by hand.
- pg_upgrade alternative: When a planned outage is acceptable, pg_upgrade with the swap option in PostgreSQL 18 is a simpler route.
- Statistics retention: PostgreSQL 18 pg_upgrade retains planner statistics, which can reduce post-upgrade slowdowns.
Run a rehearsal against a copy of production and measure the cutover window before you commit to a method.
Logical replication is the method that works between different platforms, such as Linux and Windows. Because it sends logical row changes rather than data files, the publisher and subscriber can run different operating systems. Physical streaming replication requires the standby to run the same major version and a compatible platform, since it replicates the exact block layout. Use logical replication for a migration to another operating system or a hybrid estate, and use streaming only when both sides run the same platform.
- Platform independence: Logical changes travel as row data, so the subscriber can run on a different operating system.
- Data types and extensions: Confirm that every data type, extension and collation used on the source exists on the target.
- Unsupported objects: Sequences, large objects and DDL must be recreated or migrated separately.
- Physical standby limits: Streaming standbys stay tied to the same platform and major version as the primary.
- Authentication: Check that client authentication methods, such as GSSAPI, SSPI or LDAP, match the target's directory setup.
Confirm the target's OS, extensions, collation and authentication setup with your DBA before the migration plan is signed off.
How a major upgrade with logical replication runs in phases
This sequence moves a PostgreSQL database to a newer major version by copying changes into a prepared target, so the cutover window stays short while the team checks the data before switching traffic. The documented downtime covers the switch itself, and the preparation and verification work decides how much total effort the upgrade takes.
Confirm supported versions and the target
Check the source and target major versions against the PostgreSQL versioning policy, and confirm the target is a release still inside its support window at the time of the cutover. The database owner records the source version, the target version, the extensions in use and the applications that connect to the database. The step is done when the target version and the cutover plan are written down and agreed with the application owners.
Create the schema on the target separately
Logical replication does not copy DDL, so the schema must be created on the target by a separate step, using a schema dump or a migration tool that the team already trusts. Table definitions, indexes, constraints, views, functions, roles and grants all need to exist before the subscription starts. The step is done when a schema comparison between source and target shows no unexpected differences in tables, partitions and indexes.
Set up publication and subscription
On the source, create a publication that lists the tables to replicate, including partitioned tables, since logical replication handles only tables. On the target, create a subscription that connects to the source and starts the initial table copy. The step is done when the subscription reports that each table is replicating and the publication lists every table in scope.
Let the initial copy catch up
The subscriber copies each table in full, then applies ongoing changes from the source until it is close to the primary. Watch replication lag and the state of each table, and confirm that the source has enough retained WAL for the copy to finish. The step is done when every table is in the ready state and lag stays low under normal write load.
Copy sequences and large objects manually
Sequence values and large objects are not replicated, so they must be copied by hand just before cutover. Set each sequence on the target to the value the source has reached, and export any large objects with their OIDs and move them across. Applications that rely on these values will fail or repeat keys if this step is skipped. The step is done when the sequence values and large object counts on the target match the source at the moment the source is made read-only.
Verify data before switching traffic
Compare row counts, checksums or sampled rows for each replicated table, and run the application's own test suite or key business queries against the target. Review the results with the database and application owners, and record any mismatch and its cause. The step is done when the verification report shows no open differences, or when each difference is explained and accepted in writing. This is usually the largest share of the total effort, so ask any partner for a written verification plan in the quote.
Cut over and confirm the switch
Stop writes on the source, let the subscription apply the final changes, then point applications at the target and restart them as needed. The documented downtime for this switch is several seconds, but the surrounding freeze, DNS or connection string changes and application restarts can extend the window. The step is done when the target accepts writes, applications connect without errors, and the source is kept in a rollback-ready state for an agreed period.
Operating each method: monitoring, backups and day-two work
This table compares what each replication method asks of your team after go-live: lag monitoring, handling divergence on subscribers, backup and recovery, schema changes and skills. Read each row as a question to put to your own platform and staff, because the answers decide which method stays manageable at your size. The main takeaway is that physical standbys are simpler to keep identical, while logical replication shifts work onto schema coordination and data reconciliation.
| Operating concern | Physical streaming replication | Logical replication |
|---|---|---|
| Replication lag monitoring | Monitor standby replay and write lag on the primary and standby, and alert on growth against your recovery targets. | Monitor per-subscription lag and slot retention on the publisher, since an inactive replication slot keeps WAL on disk. |
| Divergence and missing rows | Standbys are byte-level copies, so the usual operational risk is failover timing, not row-level drift. | Subscribers can diverge if someone writes to them or if a publication is changed. Plan reconciliation checks and a process for resyncing tables. |
| Backup and point-in-time recovery | Base backups plus WAL archiving support point-in-time recovery of the whole cluster. Confirm the scope in the continuous archiving documentation. | Logical replication does not replace backups. The subscriber and publisher each need their own backup and recovery plan, covering objects the replication does not carry. |
| Schema change coordination | DDL flows to standbys automatically because the standby replays the same WAL. | DDL is not replicated, so every schema change must be applied to publisher and subscriber in a planned order, with tested rollbacks. |
| Sequences and large objects | Covered by the physical copy of the cluster. | Sequence values and large objects are not replicated, so cutover plans must set sequences and move large objects separately. |
| Failover and switchover | PostgreSQL does not detect primary failure on its own, so automatic failover needs external tools. Confirm the tool and its tested runbook. | Switching writers means redirecting application connections and confirming subscriber catch-up before cutover. Test this path before a migration window. |
| Skills the team needs | Operators need streaming replication, WAL archiving, failover tooling and recovery testing. | Operators need publication and subscription design, conflict handling, sequence management and migration rehearsal skills. |
Questions teams ask before replicating PostgreSQL
Can logical replication replace streaming replication for high availability?
No, not on its own. Logical replication copies row changes for selected tables, while streaming replication ships the write-ahead log so a hot standby matches the primary block for block. The PostgreSQL documentation notes that logical replication does not carry DDL, sequence data or large objects, so a logical subscriber is not a complete failover target. PostgreSQL also does not detect a primary failure on its own, so automatic failover needs an external tool such as Patroni or CloudNativePG in either design. Use streaming for the HA standby, and add logical replication only where you need a table subset or a cross-version copy.
Does logical replication work between PostgreSQL 14 and 18?
Yes. The PostgreSQL upgrading documentation states that logical replication works between different major versions, which is why it is one of the documented routes for a major upgrade. The publisher and subscriber can differ in major version, but the subscriber must still receive the schema from your own deployment process, since DDL is not replicated. Confirm the exact version pairing you plan to run against the PostgreSQL versioning policy and the release notes for each version before you commit to a path. For planning, PostgreSQL 14 is supported until November 12, 2026, PostgreSQL 15 until November 11, 2027, PostgreSQL 16 until November 9, 2028, PostgreSQL 17 until November 8, 2029 and PostgreSQL 18 until November 14, 2030.
How much effort does a logical replication cutover take, and what drives it?
The effort depends on schema parity, write volume and how many objects sit outside replication. The PostgreSQL documentation describes a major upgrade through logical replication with only several seconds of downtime, but that figure assumes the schema is already identical on both sides and the application can switch connections quickly. The main drivers are the number of tables without primary keys, which the replication identity model depends on, the size of the initial table copy, the backlog of changes that must catch up, and the work to recreate sequences, large objects and DDL on the subscriber. Ask any partner for a written cutover plan with a rollback step before work starts.
What must the team supply for logical replication to run safely?
The team must supply several things that replication does not handle. Schema management is the first: the subscriber needs the same tables and structure, and DDL changes must be applied in both places in a controlled order. Sequence handling is the second: sequence values are not replicated, so the cutover plan must set them on the new primary. Monitoring is the third: track replication lag, slot retention on the publisher, and subscription errors, because an inactive replication slot keeps WAL on disk. Large objects also need their own copy process. Document who owns each of these items before the engagement starts.
Can our in-house team run logical replication without outside help?
A team that already operates PostgreSQL backups, restores and monitoring can usually run a simple table-subset replication without outside help, provided it has tested the cutover in a non-production environment. The harder cases are schema drift between publisher and subscriber, cross-platform copies between Linux and Windows, and consolidating several databases into one. Those cases need someone who can reason about replication identity, conflicts and sequence state. DeployOpen plans, implements, documents and supports self-hosted PostgreSQL inside your own infrastructure, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts. Ask for a written scope that lists which tables, sequences and objects are covered.
How does the PostgreSQL support window affect when we should replicate?
The support window sets a deadline, so plan the migration to finish with room to spare before it. PostgreSQL 14 is supported until November 12, 2026, which makes it the most urgent version to move off. PostgreSQL 15 is supported until November 11, 2027, and PostgreSQL 16 until November 9, 2028. PostgreSQL 17 runs until November 8, 2029, and PostgreSQL 18 until November 14, 2030, according to the PostgreSQL versioning policy. Because minor releases arrive at least every three months, a steady patch cadence is part of the same plan. Start the replication setup early enough that a failed cutover still leaves you on a supported version.
Which replication method should we use for disaster recovery in another region?
Streaming replication is usually the first option to evaluate for a full standby in another site, because it copies the whole cluster and supports hot standby reads. Logical replication fits when the remote copy needs only some tables or a different major version. Either way, a standby is not a backup. Confirm your backup approach against the PostgreSQL continuous archiving and point-in-time recovery documentation, and test restores on a schedule. Ask your team to define recovery point and recovery time targets first, since those values decide which method and how much monitoring the design needs.
What drives the cost of each replication setup
The cost of a physical standby and the cost of a logical subscriber come from different places. A physical streaming standby is a byte-for-byte copy of the whole cluster, so its cost is mostly the second server or VM, its storage, its network path and the monitoring and failover tooling that decides when to promote it. Logical replication costs less to host per subscriber but costs more to design and keep correct. Someone must script the schema transfer, because PostgreSQL 18 logical replication does not replicate DDL, sequence data or large objects. That work is engineering time, and it is paid once for the design and again whenever a schema change lands on the publisher. Ask any quote to name which of these items it prices separately: standby or subscriber hosts, DDL and sequence transfer scripts, large object handling, and failover tooling if automatic failover is wanted.
One-time costs cluster around the cutover. These include the migration design, the decision on which tables and sequences move and how, the test that proves row counts and checksums match, and at least one cutover rehearsal against a copy of production. Testing a logical migration usually takes more effort than testing a physical standby, because the reader must check that every table in scope, including partitioned tables, is present on the subscriber and that sequences were advanced by hand. Ask the provider to list the rehearsal runs, the validation queries they will use, and the rollback path if a subscriber falls behind during cutover. Illustrative example: a team that moves three tables and forgets their sequences will find the subscriber accepting writes that collide with existing keys on the first insert after promotion.
Recurring costs are where the two setups diverge most over time. A physical standby needs replication lag monitoring, failover testing and coordinated minor updates, which PostgreSQL describes as replacing executables and restarting. A logical setup adds drift checks between publisher and subscriber schemas, coordination of every DDL change across both sides, and monitoring of replication slots, since an unconsumed slot holds back cleanup on the publisher. Major version upgrades add another recurring decision. Logical replication supports cross-version moves, but the team still has to plan and rehearse each upgrade. When you request a quote, ask for the recurring scope in writing: monitoring stack, drift check frequency, upgrade support windows, and who answers when a slot stops advancing. DeployOpen does not publish prices, and quotes follow from the written scope.
How to pick the method in four decisions
This sequence settles whether you need physical streaming replication, logical replication, or both before you touch a configuration file. Each step names the documented limit that could rule out an option, so the team leaves with a method it can defend in a design review.
Define the primary goal
Decide first whether the job is keeping a standby ready to take over (availability) or moving a subset of data somewhere else (data movement). The database owner and the application owner should agree on this in writing, because it sets every later choice. Physical streaming replication copies the whole cluster at the block level, so it targets availability. Logical replication works on data changes and targets movement. Done means one sentence in the design record names the primary goal and the people who signed it off.
List the objects that must move
Inventory every object the target needs: tables, partitioned tables, schemas, DDL, sequences, large objects and extensions. PostgreSQL 18 logical replication replicates only tables, including partitioned tables, and does not carry the schema or DDL commands, sequence data or large objects. If the target needs any of those, logical replication alone will not produce a complete copy, and you must plan a separate schema load and sequence handling. Done means a signed object list that the team has checked against the documented restrictions page.
Check source and target versions and platforms
Record the major version and operating system of the source and the target. Logical replication is documented to work between different PostgreSQL major versions and across platforms such as Linux and Windows, which makes it relevant for cross-version and cross-platform copies. Physical streaming replication requires a compatible binary layout between primary and standby, so a standby is normally built on the same major version. Confirm the source version against the supported-version list and the end-of-life dates for each major release before choosing a target. Done means a written version matrix, and a note that the chosen target major version is still supported.
Test the chosen method with a rehearsal copy
Run the chosen method against a non-production copy of the database with realistic write activity. For logical replication, watch for changes to the table set, identity columns that lack a primary key, and sequences that the target must advance manually at cutover. For physical replication, confirm the standby applies WAL under load and that synchronous or asynchronous mode matches your data-loss tolerance. Record the observed cutover interruption from your own test. Done means a rehearsal log that shows replication lag, object parity checks and the measured switch step.
Decide whether failover tooling is needed
PostgreSQL does not detect a primary failure or notify the standby, so automatic failover requires an external tool such as Patroni on virtual machines or an operator on Kubernetes. If the requirement is automatic promotion, physical standbys plus a failover manager is the usual pattern, and logical replication alone does not meet it. If the requirement is a manual, planned switchover, the team can document that procedure instead. Done means a recorded decision on automatic or manual failover, with the named tool if automatic.
Decide whether read scaling is needed
Physical hot standby servers serve read-only queries, which suits reporting or read-heavy applications on the same major version. Logical subscribers are writable copies of a table subset, so they fit targeted reads only when the application can tolerate the subset and the replication delay. Confirm which queries will move, how stale results may be, and whether the application routes reads itself or through a connection layer. Done means a documented read routing plan with an agreed staleness limit.
Confirm the upgrade path and rollback
If the replication is for a major upgrade, compare logical replication with pg_upgrade and dump-and-restore on downtime, object coverage and rollback. Logical replication is documented to allow major upgrades with only several seconds of downtime, but only for the replicated objects. Plan the rollback as a reverse replication or a retained source cluster, and confirm the procedure with the vendor or the upgrade documentation for your exact versions. Done means a signed cutover runbook that names the objects handled outside replication and the rollback trigger.
How DeployOpen scopes and delivers PostgreSQL replication work
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including PostgreSQL replication designs. Each engagement starts from a written scope that sets out which replication method, which tables and which versions are in play before any work begins.
How we scope
- Confirm whether the need is a hot standby for failover or a table subset, cross-version or cross-platform copy.
- List the tables, partitioned tables, sequences, large objects and DDL changes that the design must handle separately.
- Agree the PostgreSQL versions, target hosts and network paths in writing before work starts, as engagements are fixed-scope.
How we build
- Configure streaming replication with the synchronous or asynchronous commit behavior your recovery targets require.
- Set up logical publications and subscriptions, with replica identity checked for each replicated table.
- Test failover or cutover steps, including the external tooling needed for automatic failover, against your own environment.
How we hand over
- Document the replication topology, the replication identity of each table and the sequence resync steps.
- Provide runbooks for switchover, cutover, rollback and monitoring of replication lag on your own systems.
- Walk your platform and database teams through the restore and upgrade procedures they will run after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the original project.
- Revisit the design when PostgreSQL minor or major releases change your upgrade path or support window.
- Ask for a written quote from your scope so the cost of each support tier is clear before you commit.
