<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt" -->

---
title: Patroni and logical replication for PostgreSQL:...
description: When using logical replication on top of physical replication in a Patroni-managed PostgreSQL cluster, a manual failover can cause data loss on lagging logical...
canonical: https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Patroni and logical replication for PostgreSQL: Preventing data loss during failovers | daily.dev
og:description: When using logical replication on top of physical replication in a Patroni-managed PostgreSQL cluster, a manual failover can cause data loss on lagging logical...
og:url: https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt
og:image: https://api.daily.dev/og/posts/EgaZaMrGt.png
og:image:alt: Patroni and logical replication for PostgreSQL: Preventing data loss during failovers
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Patroni and logical replication for PostgreSQL: Preventing data loss during failovers

**[Palark Blog](https://daily.dev/sources/palark-blog)** · 10 min read · 4 upvotes · 0 comments

## Summary

When using logical replication on top of physical replication in a Patroni-managed PostgreSQL cluster, a manual failover can cause data loss on lagging logical replicas — even when the physical cluster itself loses no data. This happens because Patroni creates a new logical replication slot on the promoted replica using the current LSN, skipping any WAL changes the logical replica hadn't yet consumed. The post walks through a hands-on reproduction of the problem using iptables to simulate a leader failure, then explains two solutions: using PostgreSQL 17's native replication slot synchronization (with `sync_replication_slots`, `hot_standby_feedback`, `synchronized_standby_slots`, and the `failover` slot parameter), and upgrading to Patroni 4.1+ which natively avoids interfering with failover-labeled slots. Together, these allow fault-tolerant logical replication using only built-in PostgreSQL features.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://palark.com/blog/patroni-postgresql-logical-replication-failover>

## Questions this post answers

### Why does my logical replication subscriber lose data after a Patroni failover even though the physical replica was fully in sync?

When automatic failover is disabled and replicas are tagged nofailover: true, Patroni does not pre-create logical replication slots on them. During a manual failover, Patroni creates a brand-new logical slot on the new leader starting at the current LSN, discarding any unconsumed changes a lagging logical replica had not yet received, which are then permanently lost.

_Teams running Patroni with logical replication can track fixes like this on daily.dev before hitting the same data loss._

### How do I prevent data loss in logical replication slots during PostgreSQL failovers?

Use PostgreSQL 17's native replication slot synchronization: enable sync_replication_slots and hot_standby_feedback on physical replicas, create logical slots with failover=true, and set synchronized_standby_slots so the WAL sender waits for physical replicas to confirm receipt before sending to logical subscribers. Pair this with Patroni 4.1.0+, which stops managing failover-tagged slots, avoiding the need for manual ignore_slots configuration.

_Database administrators planning a PostgreSQL and Patroni upgrade can follow guidance like this via daily.dev._

### What changed in Patroni 4.1.0 regarding logical replication slots?

Patroni 4.1.0, released September 23, 2025, merged a change that stops Patroni from interacting with any replication slots that have the failover option set. This lets PostgreSQL's own slotsync worker fully manage synchronization of failover-enabled logical slots, removing the need to add those slots to Patroni's ignore_slots configuration.

_Engineers tracking Patroni release changes can stay ahead of breaking behavior shifts through daily.dev._

## Similar posts on daily.dev

- [When Patroni Silently Deletes Your Replication Slots](https://daily.dev/posts/when-patroni-silently-deletes-your-replication-slots-elvtrgz86) · Planet PostgreSQL · 0 upvotes · 0 comments
- [When failover isn’t safe: Building high-availability PostgreSQL on Kubernetes](https://daily.dev/posts/when-failover-isn-t-safe-building-high-availability-postgresql-on-kubernetes-nljmhojvb) · Datadog · 4 upvotes · 1 comments
- [Failover slot synchronization in PostgreSQL](https://daily.dev/posts/failover-slot-synchronization-in-postgresql-la77xcrol) · Planet PostgreSQL · 0 upvotes · 0 comments
- [Architecture behind pg\_hardstorage: The replication protocol](https://daily.dev/posts/architecture-behind-pg-hardstorage-the-replication-protocol-dctuudkmo) · CYBERTEC PostgreSQL · 8 upvotes · 0 comments

---

Tags: [#postgresql](https://daily.dev/tags/postgresql)

[View this post on daily.dev](https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Patroni and logical replication for PostgreSQL: Preventing data loss during failovers","url":"https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt"},"datePublished":"2026-07-17T10:42:20.759Z","dateModified":"2026-09-14T06:01:16.154Z","description":"When using logical replication on top of physical replication in a Patroni-managed PostgreSQL cluster, a manual failover can cause data loss on lagging logical...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/48e0b5448cc30ec9c0562a64d3caa1a3?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/48e0b5448cc30ec9c0562a64d3caa1a3?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Palark Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Palark Blog","logo":"https://media.daily.dev/image/upload/s--Cwc93sPp--/f_auto,q_auto/v1780213236/logos/palark-blog?_a=BAMAMiWQ0","url":"https://daily.dev/sources/palark-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"postgresql","timeRequired":"PT10M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Palark Blog","item":"https://daily.dev/sources/palark-blog"},{"@type":"ListItem","position":3,"name":"Patroni and logical replication for PostgreSQL: Preventing data loss during failovers"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/patroni-and-logical-replication-for-postgresql-preventing-data-loss-during-failovers-egazamrgt#faq","mainEntity":[{"@type":"Question","name":"Why does my logical replication subscriber lose data after a Patroni failover even though the physical replica was fully in sync?","acceptedAnswer":{"@type":"Answer","text":"When automatic failover is disabled and replicas are tagged nofailover: true, Patroni does not pre-create logical replication slots on them. During a manual failover, Patroni creates a brand-new logical slot on the new leader starting at the current LSN, discarding any unconsumed changes a lagging logical replica had not yet received, which are then permanently lost. Teams running Patroni with logical replication can track fixes like this on daily.dev before hitting the same data loss."}},{"@type":"Question","name":"How do I prevent data loss in logical replication slots during PostgreSQL failovers?","acceptedAnswer":{"@type":"Answer","text":"Use PostgreSQL 17's native replication slot synchronization: enable sync_replication_slots and hot_standby_feedback on physical replicas, create logical slots with failover=true, and set synchronized_standby_slots so the WAL sender waits for physical replicas to confirm receipt before sending to logical subscribers. Pair this with Patroni 4.1.0+, which stops managing failover-tagged slots, avoiding the need for manual ignore_slots configuration. Database administrators planning a PostgreSQL and Patroni upgrade can follow guidance like this via daily.dev."}},{"@type":"Question","name":"What changed in Patroni 4.1.0 regarding logical replication slots?","acceptedAnswer":{"@type":"Answer","text":"Patroni 4.1.0, released September 23, 2025, merged a change that stops Patroni from interacting with any replication slots that have the failover option set. This lets PostgreSQL's own slotsync worker fully manage synchronization of failover-enabled logical slots, removing the need to add those slots to Patroni's ignore_slots configuration. Engineers tracking Patroni release changes can stay ahead of breaking behavior shifts through daily.dev."}}]}
```

