# 4.3 The Town Crier (Logical Replication)
So far, we’ve talked about a single elephant in a single depot. But what if the depot is too small? What if you need an elephant in New York to know exactly what the elephant at the main branch in London is doing?
## The Crier's Scroll
Postgres has a way of sharing its Pocket Diary with the world. This is called **Logical Replication**.
To understand why this is special, you must contrast it with **Physical Replication**.
- **Physical Replication**: This is like **shipping the literal bricks of the building**. You send the exact 8KB shipping containers (Pages) from one depot to another. It’s incredibly fast, but both depots must be identical—same version, same floor plan, same everything!
- **Logical Replication**: This is like **shipping the scroll**. You don't send the bricks; you send the *recipe* for what changed. "Add one peanut to the shelf."
Because you are only shipping the _meaning_ of the changes, the other depot can have a completely different floor plan, or even run a newer version of Postgres. This makes it the perfect choice for **Upgrades** (where you move data to a newer elephant) or **Selective Syncing** (where you only want to share the `dishes` table, not the whole pantry).
Instead of just keeping his notes to himself, the London elephant becomes a **Publication**. He hires a **Town Crier** (the Logical Decoding worker) to stand on the roof of the depot.
```sql
-- Making the Cafe's menu public
CREATE PUBLICATION cafe_news FOR TABLE dishes, drinks;
```
Every time a new scribble is committed to the diary—a new jam order or a tea-party invite—the Crier shouts it out across the ocean. "Hear ye! Hear ye! Mrs. Higgins bought a teapot!"
## The Listener's Notebook (Subscription)
In New York, another elephant is acting as a **Subscription**. He has a dedicated worker sitting on his roof with a telescope, listening for the London Crier.
```sql
-- New York branch subscribing to the London menu
CREATE SUBSCRIPTION ny_branch_sync
CONNECTION 'host=london-cafe port=5432 user=replicator password=peanuts dbname=elephant_cafe'
PUBLICATION cafe_news;
```
Every time the worker hears a change—_"London just added a new customer!"_—he writes it down and hands it to the New York elephant, who immediately performs the same action in his own depot. It’s like a worldwide game of Telephone, but one where everyone actually listens!
With **Publications and Subscriptions**, you are only shipping the _meaning_ of the changes. New York can have a completely different filing cabinet layout, or even run a different version of Postgres, and it can still keep up with the news from London. It’s like translating a recipe from English to French; as long as the cake comes out the same, the kitchen layout doesn't matter!
## The Bookmark (Replication Slots)
But what if the New York worker falls asleep? Or what if a storm blocks the telescope?
The London elephant is very considerate. He doesn't want the New York elephant to miss any news! So, he uses a **Replication Slot**—basically a **Heavy Metal Bookmark** that he clips onto the page in his Pocket Diary where New York last stopped reading.
Even if New York is offline for hours, the London elephant **refuses to throw away his old diary pages** (WAL files) until he knows New York has seen them. He just keeps hold of that bookmark until the telescope worker wakes up and catches up.
## The Cost of Shouting (Physical Resources)
Even the Town Crier needs to be paid in peanuts! Logical replication isn't "free" labor for the elephant; it consumes real resources in both depots.
### On the Source (Publication)
* **CPU (Decoding Sweat)**: The London elephant has to hire a **Logical Decoder** worker. This worker spends all day reading the Pocket Diary and translating "binary scribbles" into "human news." This takes extra CPU cycles every time you write data.
* **Memory**: The Decoder needs a small "Holding Pen" (Buffer) in memory to organize changes before shouting them. If your transactions are huge, this pen might overflow to the Frozen Pantry!
* **Disk (The Storage Hazard)**: As we saw with the **Heavy Metal Bookmark** (Replication Slot), if the news isn't delivered, the London elephant's pockets fill with WAL files. Because he's legally obligated to keep the notes until they're read, a "Stale Slot" can eventually crash the entire depot by filling up the disk!
### On the Target (Subscription)
* **CPU & I/O (The Busy Scribe)**: The New York elephant has to actually *perform* the work London told him about. He’s re-running the inserts and updates, which means he’s sweating just as much as the London elephant did.
* **Network (The Messenger)**: Shouting across the ocean takes bandwidth. If you're replicating a billion-row table, your "telescope worker" is going to be very, very busy.
> [!TIP]
> Always monitor your **[[Chapter 6/6.0 - The Waiting Game (Workloads & Locking)|Wait Events]]** on the subscriber! If you see `WalReceiverWait`, your network might be too slow for the news.
> [!WARNING]
> If the New York branch stays offline too long, the London elephant's pocket will get stuffed with millions of old diary pages! A "Stale Slot" can eventually fill up the entire depot's storage (the Frozen Pantry). Remember to check your bookmarks:
```sql
-- Checking who is currently reading the news
SELECT slot_name, active, restart_lsn FROM pg_replication_slots;
```
This "Logical" connection is the secret sauce for moving data between different systems, upgrading your database without downtime, and eventually building the massive, interconnected networks we'll explore in **[[Chapter 7/7.0 - The Elephant in the Clouds (Distributed Storage)|Chapter 7: The Cloud Scales]]**.
---
| ← Previous | ↑ Table of Contents | Next → |
| :--- | :---: | ---: |
| [[Chapter 4/4.2 - The Recovery Parade (Crash Recovery)\|4.2 The Recovery Parade (Crash Recovery)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 4/4.4 - The Pinky Swear (Transactions)\|4.4 The Pinky Swear (Transactions)]] |