When Cloud Came to Stay at the Village Bed and Breakfast

Let’s say the asteroid hits.

Not metaphorically. Actually hits. The on-prem site where your PostgreSQL primary live, where your local cluster runs, where your data has been living safely under your own roof, is gone. Not temporarily unreachable. Gone.

Everything you built locally is ash.

The question that arrives with that moment is stark and unavoidable:

Does the cloud become primary?

And if it does, who decides?

Most systems you’ll read about answer this with automation. The architecture watches. The primary stops heartbeating. After some timeout, the system automatically promotes a cloud replica to primary. DNS updates. Applications reconnect. Life continues.

It sounds comforting. Clean. Responsible.

It’s also a lie.

Here’s why.

When the local primary stops responding, the system cannot know why. It might be an asteroid. It might be a fiber cut. It might be a power failure that recovers in minutes. It might be a network misconfiguration, a human mistake, or something actively malicious.

From the system’s perspective, all of these look identical. It only knows absence.

So when it “decides” to promote the cloud replica based on a timeout, it isn’t making an informed decision. It’s making a guess. And if that guess is wrong, if the local primary returns while the cloud is now acting as authoritative, you don’t have a database problem anymore.

You have two systems claiming truth, divergent histories, and transactions that exist in one reality but not the other. That’s not something automation resolves cleanly. That’s something humans spend weeks untangling, deciding which version of history they’re willing to keep.

This is why the smartest databases refuse to auto-promote.

PostgreSQL doesn’t do it. Designed well, neither should your architecture.

So what actually happens when the asteroid hits?

The local primary is gone. The cluster is gone. The storage is gone. Replication stops. Heartbeats stop. From the cloud’s perspective, nothing is talking to it anymore.

And then, nothing happens.

The cloud replica sits there, following a primary that no longer exists. It has data, as current as replication allowed, but it does not promote itself. The system does not decide for you.

Instead, it waits.

Somewhere else, a human operator wakes up to alerts. They read the situation. They understand what happened. They make a choice.

“The local site is physically destroyed.”

“I accept this recovery point.”

“Promote this replica.”

Only then does the cloud become primary.

That action is auditable. It’s intentional. It’s attributable. And it’s irreversible in exactly the way authority transfer should be.

This distinction matters more than it seems.

Automated systems decide based on absence. They optimize for uptime. When the wires go quiet, they assume the worst and act.

Humans decide based on context. They optimize for continuity of truth. They can answer questions machines cannot: Is this a partition or a crater? Do we accept this fork in history? Are we willing to make this irreversible?

Once that decision is made, once a human says “promote”, everything else can be fast. Promotion can be scripted. DNS can update in seconds. Applications can reconnect. Automation shines after authority is settled.

But that decision itself cannot be delegated to a timeout.

It has to be witnessed.

Here’s the shift that changes how you think about the cloud in a local-first system:

The cloud stops being a backup and becomes a guest.

Not invited out of desperation. Invited intentionally, with clear boundaries, for the specific strengths it brings.

A guest in a village doesn’t own the house. Doesn’t make the rules. Doesn’t decide what happens when the door is shut. But when things are working well, they contribute. They carry weight. They make the whole system more resilient.

The cloud brings distance, durability, reach, and recovery. It offers professional storage, geographic separation, and a place to stand when something unthinkable happens locally. But it brings these as offerings, not ownership claims.

And crucially, the village decides when and how to use them.

Once you frame it this way, with cloud as guest and not landlord, a different architecture becomes possible.

Instead of a single global truth that’s supposed to live everywhere at once, you get something quieter and stronger. You get houses: clusters that are sovereign, capable of running alone, keeping their own memory, surviving their own failures. You get federation: chosen cooperation, shared intent, deliberate replication without dependency. You get a constitution in the form of GitOps, where every house converges on the same declared shape without bespoke negotiation. And you get a shared language, DNS, o services know each other by name, not by private agreements baked into code.

The cloud becomes one more house in that federation. Different strengths. Same rules. Same identity. Same boundaries around authority.

Something subtle happens here.

A pile of bare-metal servers stops being “isolated infrastructure” and becomes a house. A set of on-prem clusters stops being “legacy systems” and becomes a village. And a cloud account stops being “the modern solution” and becomes a guest contributing to something larger.

None of these surrender their nature. They simply recognize each other and agree on how to talk.

Think about the person who’s been running their own servers for years. They predate “cloud-native.” They never adopted the cloud patterns because they owned their infrastructure and it worked. They built redundancy carefully, kept memory local, and treated failure as something to understand, not smooth over.

To them, the cloud narrative always sounded like a demand: give up control, trust someone else, adopt our abstractions.

But they were already doing the hard part.

They understood that authority must be clear. They knew memory can’t be treated as disposable. They built systems that survived failure without lying about it.

They were already building local-first architecture. They just didn’t have a name for it, and they didn’t know they could join a larger federation without giving up what they’d built.

The village model says: you don’t have to change. You just have to organize.

Specifically, you organize around two things.

Shared intent, expressed through GitOps. Every house converges on the same declared shape. A new house joins by adopting the template, not by negotiating bespoke state.

And shared language, expressed through DNS. Services talk by name, not by hardcoded location. A stable naming grammar lets things move, fail, and recover without rewriting the world.

Those two together, convergent delivery and stable naming, are the civic infrastructure. Everything else is implementation detail.

Once that’s in place, behavior follows naturally.

Houses replicate deliberately. Failures stay local. New houses join without disruption. Promotions happen intentionally, when humans decide they should.

The cloud house hosts replicas, keeps archives, serves as a public front door when needed, and restores the system if the unthinkable happens. But it does not rewrite rules, decide authority, silently move truth, or pretend it was always primary.

It is subject to the same civic law as every other house.

This is what lands for people who’ve been running their own infrastructure all along:

You were right.

Local isn’t fragile if it’s federated. Authority isn’t weak if it’s intentional. Memory isn’t endangered if it’s kept close and replicated deliberately.

You don’t need to migrate anywhere. You don’t need to adopt a vendor’s story. You just need to give your house a name, decide its shape, and let others converge on the same pattern.

And if you want, you can invite the cloud to stay, at the village bed and breakfast, for the moments when distance and durability matter.

When the asteroid hit, and eventually, something will, the system doesn’t panic.

The local site goes dark. Alerts fire. A human reads the situation. They check recovery points. They understand the tradeoffs. And then they decide.

“Promote the cloud house.”

One command.

Authority moves. DNS updates. Applications reconnect. The village keeps running, with a different center of gravity, temporarily.

And there is a witnessed moment, auditable and explicit, when truth moved. No split-brain. No pretend continuity. No system lying about what it is.

Just federation, and human intention.

This is what changes when you stop treating the cloud as the solution and start treating it as a guest.

It doesn’t need to be omnipresent. It doesn’t need to decide things. It just needs to be useful when conditions require it.

And by respecting the village’s rule, by accepting identity, naming, and authority boundarie, it becomes something genuinely trustworthy.

Not because it’s cloud.

But because it knows its place.