Databases on a Decentralized Cloud

Fluxers! Stateless apps are the easy case for any cloud: if a machine goes away, start the container somewhere else and carry on. A database is the opposite. Its whole job is to keep data safe across machines that can come and go — and on a decentralized cloud, those machines are run by thousands of independent operators across more than 50 countries. Here is how Flux runs databases today, and where the roadmap takes them next.

PostgreSQL with real high availability

flux-pg-cluster turns three or more Flux instances into a standard Patroni-managed PostgreSQL cluster — the same high-availability stack trusted across the industry, with etcd electing the primary. Flux adds the glue a decentralized network needs:

• Automatic discovery. The cluster finds its own members through the FluxOS location API, wherever the network placed them.
• A primary-routing proxy. Your app connects to one port, 5433, and every write goes to the current primary — across failovers, with no change to your connection string. The proxy re-checks every node every 3 seconds.
• Read replicas available directly on port 5432 when you want to spread read traffic.
• Your choice of durability. By default replication is asynchronous for speed; switch on synchronous mode and every commit waits for a replica to confirm it, so a failover loses nothing.
• Careful recovery. After a total outage, the cluster agrees on which node holds the authoritative data before anything restarts, and never wipes data unless you explicitly allow it.

And it is tested the hard way: an integration suite spins up three-node clusters, kills the leader, kills two of three nodes, and checks that the cluster recovers within set time budgets.

MySQL and MariaDB, clustered

Flux-Shared-DB clusters MySQL or MariaDB instances on separate Flux nodes into one logical database. A small operator sits in front of the engine, sequences writes on an elected master and replays them on every follower, and your application simply connects with an ordinary MySQL connection string. Regular snapshots can be kept in a synced folder so every instance holds a copy. It has been in production since 2022, and today it carries the database behind dozens of live apps on Flux, from WordPress sites to Ghost, ownCloud and Nextcloud.

Where it goes next: managed databases

Today these are building blocks you deploy alongside your app. The roadmap turns them into a product: managed PostgreSQL and MongoDB as one step in the deployment flow, with backup and restore attached. Choose a database while you deploy, and Flux takes care of the cluster.

Two more pieces make it smoother still. FluxOS v9 application specifications add proper persistent storage with sized volumes, replicas with active-standby and active-active placement, and sync-before-start ordering for apps that need their data in place first. And graceful shutdown — draining and pre-stop hooks before a node stops an app — lets a database checkpoint cleanly whenever it moves.

RPC, archive and indexing

The same thinking extends to blockchain data. The roadmap names RPC, archive and indexing services as Flux’s first capacity-selling product: archive nodes run as Flux Cloud applications, and access to RPC and node APIs is sold as a service. It pairs directly with main-chain pruning — pruned nodes stay fully able to produce blocks, while designated archive nodes preserve full history for explorers and data services. A distributed node network is a natural home for serving chain data, and the operations expertise is already in-house.

Start today

Both database operators are open source and deploy on Flux today: add the cluster image as a component of your app on cloud.runonflux.com, and follow the README in each repository. For a gentle start, see Deploy Your First App on Flux.