ZeusK8s
Bases de datos

Bases de datos que ya están en la otra región.

El estado es donde mueren los proyectos multi-región. ZeusK8s despliega MySQL, PostgreSQL, ClickHouse, Prometheus y Yugabyte con replicación global — async para apps existentes sin reescribir, o multi-master síncrono con Yugabyte cuando la consistencia no se puede comprometer.

La parte más dura de ir global, resuelta.

Los servicios stateless son fáciles de repartir entre regiones. El estado es donde se cae. El runbook de DR era un doc de Notion; el incidente real significaba recrear bases de datos a mano y rezar para que los backups fueran lo bastante recientes. La solución habitual — reescribir contra una base de datos distribuida — es un proyecto medido en trimestres que la mayoría de equipos nunca arranca.

ZeusK8s toma el otro camino. Despliega el mismo MySQL, PostgreSQL, ClickHouse o Prometheus que tu código ya usa, dile que sea global, y Zeus lo coloca entre tus clústeres y lo mantiene replicado. Escribe en una región, léelo en otra un latido después. Backups y restore point-in-time se configuran desde el principio, no se enchufan tras el primer susto.

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

Despliega desde un panel, no desde un runbook

Elige el motor, las regiones y el modo de replicación en un formulario gráfico. Zeus levanta la base de datos en tu tejido y cablea la replicación.

02

Replica entre regiones

Un primary claro para escrituras, réplicas en la región más cercana para lecturas. Tu app sigue hablando a un endpoint normal. La geografía es problema de Zeus.

03

Haz backup automáticamente

Backups programados y cifrados a almacenamiento compatible con S3 con retención que configuras una vez. El archivado WAL/binlog habilita restore point-in-time.

04

Recupera a cualquier segundo

Restaura in place o levanta una base de datos nueva desde un backup, a cualquier punto dentro de tu ventana de retención.

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.

Motores
MySQL, PostgreSQL (CNPG), ClickHouse, Prometheus, Yugabyte
Replicación
Multi-región async; lecturas en la región más cercana
Backups
Programados, cifrados, S3/GCS, políticas de retención
Recuperación
Restore point-in-time desde WAL/binlog
HA
Failover basado en quórum, promoción automática
Sizing
Calculadoras de presupuesto de memoria y sizing integradas
Sin reescribir
Las apps existentes usan un endpoint normal, sin cambios
Sin lock-in
Motores reales con protocolos estándar — dump, exporta o vete cuando quieras
Straight answers

Questions you’d actually ask.

¿Soportáis Yugabyte?

Sí. Despliega Yugabyte dentro de Zeus igual que cualquier otra base de datos — obtienes escrituras multi-master síncronas entre regiones, más el mismo networking entre clústeres, DNS, IAM, observabilidad y superficie operativa que todo lo demás. Para consistencia global estricta de escrituras, Yugabyte en Zeus es la respuesta.

¿Cuándo uso replicación async vs Yugabyte?

La replicación async (MySQL, PostgreSQL, ClickHouse, Prometheus) encaja cuando tienes una app existente y no te puedes permitir reescribir — multi-región en un fin de semana sin cambios de código. Yugabyte encaja cuando una escritura debe committear en dos regiones o no committear — sistemas financieros, inventario, cualquier cosa donde el split-brain es inaceptable. Zeus corre ambos; tú eliges el modelo de consistencia.

¿Cómo funciona el restore point-in-time?

El archivado continuo de WAL (Postgres) o binlog (MySQL) te deja restaurar a cualquier segundo dentro de tu ventana de retención, in place, o como una instancia de base de datos nueva desde un backup.

¿Dónde viven los backups?

Cifrados, en almacenamiento compatible con S3 que controlas tú, con políticas de retención que defines. Las credenciales se guardan en el store cifrado de Connections, nunca en config en texto plano.