Frequently asked questions

A self-hosted database cluster manager, in development. You run one control-plane container, add your Linux servers, and create highly available clusters of PostgreSQL, MongoDB, Valkey, Dragonfly, MariaDB Galera and Garage S3 object storage from a web console, the ecl command line, a REST API or an AI assistant. Every change is shown as a plan before it runs, and backups, monitoring and alerts are built in.

No. ElastiCluster is in development and has no release yet. Development builds already set up the control plane, sign in with two-factor codes, and add, check and approve servers with their agents. Plans and approvals are being built now. The first preview, v0.1, brings PostgreSQL high availability, and creating production clusters stays blocked until backups arrive in v0.2. The roadmap lists what each release adds.

No. The interactive demo runs the planned console in your browser with simulated data: three projects, 28 servers and 15 clusters on all six engines. Nothing is sent anywhere, and it resets when you reload the page.

ElastiCluster is designed and built by George Khananaev. The about page explains the principles behind it and how this site describes features that are still in development.

No. ElastiCluster runs databases as containers on ordinary Linux servers, with one small agent per server; the agent can install Docker for you. If your whole platform already runs on Kubernetes, a Kubernetes operator such as CloudNativePG is likely the better fit. See alternatives.

Three is the usual answer. A highly available PostgreSQL cluster uses three data members, or two data members plus a small witness server that only takes part in the etcd vote. Valkey needs a primary, a replica and three Sentinels, which fit on three servers. MongoDB replica sets and Galera clusters use three or more members, and Garage keeps three copies across three nodes. For trying it out, a planned lab mode runs three practice servers on one machine.

They keep running. High availability comes from each engine’s own mechanism (Patroni with etcd, replica-set elections, Sentinel, Galera), so failover, endpoints and log archiving work without the control plane. Scheduled backups and drills wait until it is back, interrupted operations resume where they stopped, and an external heartbeat check can alert you that it is gone.

The planned first tier is Ubuntu 24.04 and 26.04, Debian 12 and 13, and Rocky Linux or AlmaLinux 9 and 10, on amd64 and arm64. So far, development builds run on Debian 13 lab servers and Proxmox test containers; the other distributions join the automated test matrix before release.

The design targets, measured from detection to the first successful client write, are at most 45 seconds for PostgreSQL, 30 seconds for MongoDB (three or more data members, drivers that retry writes), 20 seconds for Valkey (at least two replicas) and 10 seconds for moving the Galera writer. These are targets each release must meet in automated failure tests; no release has been measured yet.

Not in place. Data is imported into a new cluster instead. For PostgreSQL, existing clusters (including ones managed by Autobase) are planned to be adopted by replication with seconds of downtime in v0.7; online migration for other engines is planned for v1.1.

Removing the agent leaves the databases running as plain containers. Backups use the engines’ standard tools and formats (pgBackRest, mariadb-backup, RDB snapshots and so on) with documented manual restores, and native tools such as patronictl, mongosh and valkey-cli keep working throughout.

Assistants use the same plans and policies as people. By default an assistant may only propose changes in production; a person approves them, and the owner of an assistant’s token can never approve that token’s requests. Read-only queries run under database roles that cannot write, instance kill switches stop all AI writes at once, and every call is audited. See AI and MCP.

No telemetry by default. The only outbound checks planned are optional update and engine-catalog checks, and they can be turned off. Agents talk only to your own control plane; servers otherwise reach only the registries and backup repositories you configure.

Agents only make outbound connections to your control plane, so servers need no inbound management port. Support for HTTP proxies and fully offline installs from signed bundles is planned for v0.8.