Press "Enter" to skip to content

Category: Replication

Consolidating Postgres Databases using Logical Replication

Published 2026-10-09 by Kevin Feasel

Dimitri Fontane explains a process:

This architecture is the one the documentation lists as “consolidating multiple databases into a single one, for example for analytical purposes”. The application developer’s version: three different applications (a shop, a CRM, a billing system), each with its own schema and its own server, all feeding a warehouse; and then the warehouse’s changes exported to something that is not Postgres.

Click through for examples, as well as what limitations you’re liable to run into along the way.

Comments closed

A Decade of Logical Replication in Postgres

Published 2026-09-23 by Kevin Feasel

Dimitri Fontaine reflects on ten years of functionality:

A long time ago I ran a write-heavy system on a hub and a handful of workers. Each worker took a share of the application traffic and wrote events locally. The hub owned the reference data (customers, plans, prices), pushed it down to the workers, and pulled every worker’s events back up to compute the invoices. The plumbing was Londiste and PgQ: triggers on every table, a queue per node, a ticker, and a Python daemon per hop. It worked, and it was a lot of moving parts to explain to anyone new.

Postgres 10 shipped logical replication in 2017, and 19 is the tenth release that has it. Every release since Postgres 10 has taken a piece of that plumbing and made it a line of SQL.

Click through for a reflection on what’s there and what has changed over the years. This first post in the series covers the hub and worker model.

Comments closed

Privilege Escalation via Replication Job

Published 2025-12-23 by Kevin Feasel

Fabiano Amorim makes note of a security concern:

Privilege escalation in SQL Server isn’t just theory – it can happen through everyday maintenance jobs. This article demonstrates how a user with roles like db_owner or db_ddladmin can exploit replication cleanup processes to gain sysadmin rights, and why monitoring trigger creation and job behavior is critical for security.

Replication is one of those things people tend not to understand very well, including the necessary permissions. It’s a lot easier simply to say, “Here’s sysadmin” because that actually works instead of giving you a cryptic error you can barely troubleshoot and that’s only thanks to a Repltalk article from 2009. And heaven help you if you’re looking at merge replication.

But as far as the article goes, I won’t say that it’s much ado about nothing. What I will, however, say is that your account needs to be db_owner or db_ddladmin first, and that does mitigate a fair amount of the risk.

Comments closed

Monitoring Replication in Redgate Monitor

Published 2025-12-16 by Kevin Feasel

Steve Jones shows off some functionality:

The monitoring capabilities in Redgate Monitor were originally fairly limited to a few counters from PerfMon. A few people had written custom metrics on sqlmonitormetrics.com that clients could use, but we’ve had customers asking for more native integrations.

We’ve done it. With version 14.2, we have added an estate view of your replication environment. In the Estate menu, there is a new entry for Replication Monitoring.

I had to check the documentation to see if merge replication was included, and it was. That’s usually the form that people avoid because it’s too hard to implement.

In practice, this doesn’t replace ReplMon or more detailed mechanisms for detailing system behavior, but it does at least provide the ability to alert if things are going wrong with the SQL Agent jobs. That probably catches about 60-70% of issues with replication, with the remaining 30-40% requiring some sort of time of flight indicator to see if data on the subscribers are keeping up to date with data on the publisher.

Comments closed

Data Replication and Columnstore

Published 2025-12-11 by Kevin Feasel

Niko Neugebauer continues a series on columnstore:

In the Columnstore Indexes space, there is a long-standing “tradition” in Microsoft to ignore the needs of the customers for data replication. It has started with with the original SQL Server 2012 release not supporting any data manipulation operations besides Partition switching. Since then it has been improved from version to version up until SQL Server 2016 where Nonclustered Columnstore Indexes has received a support for the Transactional Replication, and voila – that’s where it has stopped!

Read on for the frustration involved in moving around columnstore data.

2 Comments

PostgreSQL Synchronous Replication is Asynchronous

Published 2025-10-28 by Kevin Feasel

Jeremy Schneider doesn’t wait for a response:

Postgres database-level “synchronous replication” does not actually mean the replication is synchronous. It’s a bit of a lie really. The replication is actually – always – asynchronous. What it actually means is “when the client issues a COMMIT then pause until we know the transaction is replicated.” In fact the primary writer database doesn’t need to wait for the replicas to catch up UNTIL the client issues a COMMIT …and even then it’s only a single individual connection which waits. This has many interesting properties.

Click through for the pros and cons of this technical decision.

Comments closed

Trace Flag 1448 and Replication

Published 2025-10-23 by Kevin Feasel

Garry Bargsley covers the behavior of a trace flag:

In SQL Server environments where transactional replication runs alongside Always On Availability Groups (AGs), DBAs sometimes face a frustrating scenario: replication stalls when a secondary replica or subscriber is offline for maintenance, patching, or unexpected downtime.

By default, SQL Server’s Log Reader Agent is cautious. It only marks transactions as ready for replication once they are hardened on both the primary and all replicas. This ensures consistency across the AG, but it can also cause replication to stall if an asynchronous replica or subscriber is unavailable for an extended period of time.

Click through to see how it works and what the consequences are.

Comments closed

Postgres Migration via Logical Replication

Published 2025-10-06 by Kevin Feasel

Elizabeth Christensen makes a move:

Moving a Postgres database isn’t a small task. Typically for Postgres users this is one of the biggest projects you’ll undertake. If you’re migrating for a new Postgres major version or moving to an entirely new platform or host, you have a couple options:

Read on for those three options, when logical replication can possibly work, and the process for upgrade. It’s definitely a bit more fiddly than other options, but it’s hard to beat with respect to downtime.

Comments closed

Replication Types and Modes in PostgreSQL

Published 2025-07-11 by Kevin Feasel

Semab Tariq lays out three types of replication available in PostgreSQL:

PostgreSQL also supports replication to keep standby servers in sync with the primary server using Write-Ahead Log (WAL) files. Every change made to the database is first recorded in these WAL files on the primary server. These logs are then continuously streamed to the standby server, which applies them to stay up to date. This method ensures that all standby servers stay in sync with the primary and are ready to be promoted in case the primary server fails.

In this blog, we will explore the different types and modes of replication available in PostgreSQL to help you understand which option best fits your business needs.

Click through for the list, as well as an overview of each replication type.

Comments closed

Thoughts on Multi-Primary Replication in PostgreSQL

Published 2025-06-19 by Kevin Feasel

Jan Wieremjewicz wants to know if you really need it:

Active-active, also referred to as multi-primary, is a setup where multiple database nodes can accept writes at the same time and propagate those changes to the others. In comparison, regular streaming replication in PostgreSQL allows only one node (the primary) to accept writes. All other nodes (replicas) are read-only and follow changes.

In an active-active setup:

  • There is no single point of write.
  • Applications can write to any node.
  • The database needs a way to sort out conflicts when two nodes try to concurrently change the same data.

Read on for some of the challenges around this, tooling that is available, and thoughts on when this can be important.

Comments closed