apps/www/_blog/2026-06-04-multigres-v0-1-alpha.mdx
Today we're releasing Multigres v0.1 alpha to the open source community, the first public milestone of our mission to bring Vitess-grade horizontal scaling, high availability, and operational simplicity to Postgres. It's early, it's alpha, and we're excited to get it into your hands.
This is an open-source-only release. Multigres for Supabase is coming soon.
Multigres is a scalable operating system for Postgres: it holistically manages your Postgres instances and gives you sharding, connection pooling, automatic failover, and backup orchestration.
Postgres at scale is operationally complex: You need to manage read replicas, failovers, connection limits, backups, and more. Multigres handles these chores as a single cohesive system. And when the time comes to scale, Multigres will help you shard your database and scale it horizontally.
The v0.1 alpha introduces advanced connection pooling, automatic failovers, and a Kubernetes operator for deployment.
The Kubernetes Multigres Operator allows you to deploy and manage Multigres clusters on Kubernetes. To get started, you need a Kubernetes cluster along with a location for backups configured. The backups can be a shared file system or a cloud storage bucket like AWS S3. It is also possible to run Multigres on a local Kind cluster.
All the necessary images for running Multigres are publicly available.
Multigres treats HA as a consensus problem, and is capable of resolving split-brain scenarios without losing commits that have succeeded. The protocol implemented by Multigres is based on generalized consensus, a model that gives you flexibilities that do not exist in traditional consensus-based systems:
For more information on HA, you may read the following posts:
Multigres ships its own connection pooling solution using a two-service architecture. It consists of a multigateway that accepts client connections and routes queries, and a multipooler that manages backend connections. This architecture provides some distinct advantages over a single-process pooler.
SET ROLE impersonation. A fair-share algorithm splits a fixed connection budget across users, and pool routing is kept fast.For more information on connection pooling, you may read Two jobs, two processes: why Multigres has its own connection pooler.
Multigres uses pgBackRest for backups. Backups are taken from replicas to avoid overloading the primary.
To learn more about how a cluster bootstraps, you may read How a Multigres Cluster Bootstraps.
v0.1 is stable enough to experiment with and give feedback on. It is not yet ready for production workloads. Specific caveats: