ZeusK8s
Databases

Databases that are already in the other region.

State is where multi-region projects die. ZeusK8s deploys MySQL, PostgreSQL, ClickHouse, Prometheus, and Yugabyte with global replication — async for existing apps with no rewrite, or synchronous multi-master with Yugabyte when consistency can't be compromised.

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, ClickHouse, or Prometheus your code already uses, tell it to go global, and Zeus places it across your clusters and keeps it replicated. Write in one region, read it in another a heartbeat later. Backups and point-in-time restore are configured from the start, not bolted on after the first scare.

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.

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, Prometheus, Yugabyte
Replication
Async multi-region; nearest-region reads
Backups
Scheduled, encrypted, S3/GCS, retention policies
Recovery
Point-in-time restore from WAL/binlog
HA
Quorum-based failover, automatic promotion
Sizing
Built-in memory-budget & sizing calculators
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 — you get synchronous multi-master writes across regions, plus the same cross-cluster networking, DNS, IAM, observability, and operations surface as everything else. For strict global write consistency, Yugabyte on Zeus is the answer.

When should I use async replication vs Yugabyte?

Async replication (MySQL, PostgreSQL, ClickHouse, Prometheus) is right when you have an existing app and can't afford a rewrite — multi-region in a weekend with no code changes. Yugabyte is right when a write must commit in two regions or not at all — financial systems, inventory, anything where split-brain is unacceptable. Zeus runs both; you choose the consistency model.

How does point-in-time restore work?

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

Where do backups live?

Encrypted, in S3-compatible storage you control, with retention policies you set. Credentials are stored in the encrypted Connections store, never in plaintext config.