Skip to content

About ElastiCluster

Teams that run databases on their own servers deserve what managed cloud databases give everyone else: failover, point-in-time recovery, monitoring and safe upgrades, without Kubernetes, without hand-written automation and without handing their data to someone else.

Why it exists

The existing options each leave a gap. Some manage only PostgreSQL, some need Kubernetes, some run a single database without failover, and some are playbooks you operate from the command line. None of them lets an AI assistant help operate a fleet within limits a team sets and can audit.

ElastiCluster’s answer is a single container that plans and observes, an agent on each server, each engine’s own proven high-availability mechanism, and one rule for every change, whether it comes from a person, a script or an assistant: show the plan first.

Who is building it

ElastiCluster is designed and built by George Khananaev. The design is written down as a detailed plan before code, covering architecture, failure handling, security hardening, performance budgets and every engine, and the product is built milestone by milestone against tests that must pass before the next one starts. The interactive demo was built from that plan to see the product before it exists and to find what the plan was missing.

Principles

  1. Simple over clever One control-plane container, one agent per server, containers, proven high-availability managers and the same patterns across engines.
  2. Not in the data path Databases, failover and endpoints work without the control plane.
  3. Never invent consensus Patroni with etcd, replica-set elections, Sentinel, Galera and Garage do high availability; ElastiCluster orchestrates them.
  4. Declarative, previewable, reversible A specification becomes a plan with a diff, risk and disruption, then approval, then an operation, with revisions to go back to.
  5. Safe by default TLS on, backups on, restores to a new cluster, typed confirmation for destructive actions.
  6. AI-native, human-governed Everything is available to AI assistants through MCP, but risky changes need people.
  7. No lock-in patronictl, mongosh, valkey-cli and docker ps keep working, and the databases outlive the agent.
  8. Observable by default Health, metrics, logs and alerts without extra installs.
  9. Latest stable, tested versions A signed catalog pins engine images and upgrade paths, defaulting to the newest version that passes the tests.
  10. Flexible without one-off switches Expert needs are met by generic, validated escape hatches, such as any engine parameter or custom images, rather than hundreds of toggles.

How this site describes the product

ElastiCluster is in development. Every capability on this site carries a status: working in development builds, being built now, or planned for a named release. Product screenshots come from the interactive demo, which runs on simulated data, and are labelled as such; illustrations are labelled as illustrations. Numbers such as failover times are design targets that releases must meet in tests, and the site says so wherever they appear.

The site has no tracking or analytics. Status was last updated on 2026-10-14; the roadmap is updated as milestones land.

The name

The E and the C in the wordmark share one curved, stretched shape: elastic and cluster, written as one family of letters. ElastiCluster is not related to the open-source ElastiCluster tool for creating compute clusters on clouds, or to Elastic or Amazon ElastiCache.

Trademarks

PostgreSQL, MongoDB, Valkey, Dragonfly, MariaDB, Galera, Garage, Redis and other names mentioned on this site are trademarks of their respective owners. ElastiCluster is not affiliated with or endorsed by them; their names are used only to describe compatibility.

Try the console before it ships

The interactive demo runs the whole console on simulated data. Trigger a failover, approve an AI assistant’s plan, restore a backup to a point in time. Nothing to install.

Explore the demo See what works today