ZeusK8s
Databases

Databases that are already in the other region.

State is where multi-region projects die. ZeusK8s deploys MySQL, PostgreSQL, ClickHouse, and Yugabyte with global replication — async for existing apps with no rewrite, or synchronous multi-master with Yugabyte when consistency cannot be compromised. One ops surface for topology, backups, and failover.

The hardest part of going global, solved.

Stateless services are easy to spread across regions. State is where it falls apart. The DR runbook was a Notion doc; the real incident meant recreating databases manually and hoping the backups were recent enough. The usual fix — rewriting against a distributed database — is a project measured in quarters that most teams never start.

ZeusK8s takes the other road. Deploy the same MySQL, PostgreSQL, or ClickHouse your code already uses, tell it to go global, and Zeus places it across your clusters and keeps it replicated. Monitoring, lag, backups, and failover controls live in one board. Write in one region, read it in another a heartbeat later.

Zeus · Infrastructure · MySQL (global)
orders-db · MySQL
Global · 2 regions · async replication
Replicating
AWS · us-east-1 Primary
writer
orders-db.zeus.internal ✓ accepting writes
41ms lag
GKE · europe-west3 Replica
reader
orders-db-ro.zeus.internal ✓ in sync
Writes / s
2,480
us-east-1
Reads / s
9,140
europe-west3
Replica lag
41 ms
p99 · healthy
How it works

From zero to running.

01

Deploy from a panel, not a runbook

Pick the engine, regions, and replication mode in a graphical form. Zeus stands the database up across your fabric and wires replication.

02

Replicate across regions

A clear primary for writes, nearest-region replicas for reads. Your app keeps talking to one normal endpoint. The geography is Zeus’s problem.

03

Back it up automatically

Scheduled, encrypted backups to S3-compatible storage with retention you set once. WAL/binlog archiving enables point-in-time restore.

04

Recover to any second

Restore in place or stand up a fresh database from a backup, to any point within your retention window.

Engine honesty

One ops surface. Engine-honest recovery.

Every engine gets topology, health monitoring, backups, and failover controls in the same board. What differs is how that engine actually recovers — and Zeus shows you which path applies.

EngineModelShared monitoringZeus multi-cluster auto-arbiterManual failover / rebuild
MySQLSingle-primary ClusterSetYesYes (3+ members)Switchover, rejoin, errant-GTID
PostgreSQLCNPG streamingYesNo — guided pathSwitchover, promote, rebuild/re-clone
ClickHouseMulti-writer + KeeperYesN/A (no primary)Rebuild / restore replica
YugabyteSync multi-master optionYesHuman-gatedSwitchover, re-seed
The specifics

Built by people who run this in production.

No hand-waving. Here’s what’s actually under the hood: the kind of detail you’d expect from a platform you’re going to trust with production.

Engines
MySQL, PostgreSQL (CNPG), ClickHouse, Yugabyte
Shared ops surface
Topology, lag, health daemons, backup checks, action preflights
MySQL multi-cluster
Auto-arbiter when 3+ members; switchover, rejoin, errant-GTID reconcile
PostgreSQL / others
Guided switchover, emergency promote, rebuild paths — engine-honest recovery
Replication
Async multi-region; nearest-region reads when configured
Backups
Scheduled, encrypted, S3/GCS, retention policies
No rewrite
Existing apps use a normal endpoint, unchanged
No lock-in
Real engines with standard protocols — dump, export, or leave anytime
Straight answers

Questions you’d actually ask.

Do you support Yugabyte?

Yes. Deploy Yugabyte inside Zeus the same way as any other database — synchronous multi-master writes across regions, plus the same cross-cluster networking, DNS, IAM, observability, and operations surface.

When should I use async replication vs Yugabyte?

Async (MySQL, PostgreSQL, ClickHouse) when you have an existing app and cannot afford a rewrite. Yugabyte when a write must commit in two regions or not at all. Zeus runs both; you choose the consistency model.

Is failover automatic for every engine?

You get one ops surface for every engine. MySQL multi-cluster sets can auto-promote with the arbiter when eligible. PostgreSQL and others use guided switchover and rebuild paths that match how those engines actually recover — never a fake single button that lies about physics.

How does point-in-time restore work?

Continuous WAL (Postgres) or binlog (MySQL) archiving lets you restore within your retention window, in place, or as a new instance from a backup.

Where do backups live?

Encrypted, in S3-compatible storage you control, with retention policies you set. Credentials live in the encrypted Connections store.