---
title: 'Scale without limits: Multigres, OrioleDB, and dbarena'
description: >-
  The app your agent built in minutes stays on the same Postgres from prototype
  to petabyte.
author: 'joe_sciarrino, alexander_korotkov, daniel_mitterdorfer, aditya_maruvada'
date: '2026-10-02T10:35:00'
tags:
  - postgres
  - database
  - scaling
categories:
  - product
---
Today at Supabase Select, we announced Multigres for high availability and scalable connection pooling, and OrioleDB for high performance storage. We launched dbarena, an open benchmarks site for comparing managed Postgres providers’ performance results and costs.Every Supabase project starts with a single Postgres database. As your project grows, vertically upgrading the database’s available RAM & CPU resources can help, but it isn’t a solution to every challenge.Scaling Postgres isn’t a singular problem — users encounter new challenges at different stages of scale and under different workloads. Our users often report needing help scaling concurrent client connections, reducing the overhead of bloat and frequent VACUUM operations, increasing read and write throughput, avoiding transaction ID wraparound, and guaranteeing uptime with high availability.Our focus is to remove every scaling limitation from our users’ journey. That means tackling bottlenecks at every layer of Postgres, building in public, and making the improvements fully open source and available to the broader builder community.## MultigresMultigres is an open source operating system for Postgres, built by the team behind Vitess. It adds scalable connection pooling and automated multi-node failover to Postgres out-of-the-box. With Multigres, there's no separate pooler to run, and your app can connect far more clients than one Postgres instance can hold.Many developers are familiar with basic Primary / Standby HA architecture and its known issues. Traditionally, if the primary database fails before data has been replicated to the standby, those rows may be lost. In contrast, Multigres uses a generalized consensus protocol built on top of postgres synchronous replication. If a Multigres node fails, the cluster agrees on exactly which writes were committed before accepting new ones, then promotes a replica in seconds. You keep every committed write through the failover.Multigres runs three Postgres nodes across availability zones in one region, so losing one zone doesn't take your database down. You don't need to change your application code to move to Multigres.You can also add read replicas and gateways for more read throughput and client connections. During the alpha, our team adds them for you.Multigres is in private alpha, by invite. It works with Supabase Auth, Storage, and Edge Functions, and it's built for testing during the alpha, not production workloads. [Request access](https://supabase.com/go/multigres-early-access).## OrioleDBOrioleDB is an open source, scalable storage engine for Postgres. It replaces Postgres traditional heap storage and eliminates its fundamental limitations, such as table bloat, VACUUM overhead, and txid wraparound inherent to the limited range of 32-bit transaction IDs.With heap storage, Postgres never updates a row in place: every update writes a new row version and leaves the old one behind as a dead tuple. On hot tables with frequent updates and deletes, this creates significant bloat over time, and cleaning it up requires constant VACUUM activity. VACUUM is one of the most common causes of Postgres performance degradation and outages under load. Teams typically mitigate it with careful tuning, scheduled `pg_repack` runs, and over-provisioned compute.OrioleDB's undo log removes this problem at the source. Instead of leaving dead tuples behind, updates and deletes write page-level undo records, which the system reclaims automatically. This eliminates bloat entirely and VACUUM is no longer needed.Allowing lock-free page reads also makes OrioleDB more efficient under high concurrency, especially in IOPS use. OrioleDB delivers up to 1.8x higher throughput than Postgres heap in our public, TPC-C-derived benchmarks, published on [dbarena.com](https://dbarena.com/).> **NOTE**
>
> During the public beta, you can choose OrioleDB under advanced configuration when you create a project. You can also use OrioleDB and heap storage per table in one project, with `USING orioledb` or `USING heap`.OrioleDB uses 64-bit transaction IDs (XIDs) by default, so it avoids Postgres's wraparound problem. With 32-bit XIDs, wraparound hits after roughly 4 billion transactions and forces the database to aggressively freeze old rows. With heap storage, XIDs are directly stored in every tuple, so expanding them from 32 to 64 bits would add 8 bytes to every row version. That simple 8-byte change cascades across billions of row versions with dead tuples, resulting in more pages, more I/O, greater cache pressure, and larger indexes.Because OrioleDB replaces heap's vacuum-based MVCC with an undo log, it sidesteps this constraint entirely: transaction metadata can use 64-bit XIDs without inheriting heap's legacy tuple format.OrioleDB has been under active development by the Supabase team and open source contributors since 2021. Supabase employs the engine's creators, including major Postgres contributor Alexander Korotkov, who have shipped eighteen beta releases.## dbarena![A dbarena comparison of two XLarge configurations, showing throughput per dollar, monthly cost, throughput, p95 latency, and throughput over time](/images/blog/select-2026-scale-without-limits/dbarena.png)[dbarena.com](https://dbarena.com) publishes open, reproducible database benchmarks across providers: the benchmark code, published methodology, downloadable raw data per result, and shareable comparison links. It compares Supabase, Amazon RDS, and Google Cloud SQL at launch. For each run, dbarena reports transactions per dollar, monthly total cost, transactions per minute, p95, and machine specs, and it plots throughput over time.Developers evaluating hosted Postgres have few trustworthy sources for comparing providers. Vendor benchmarks often run under favorable conditions, community benchmarks are one-off snapshots, and a rigorous in-house evaluation costs weeks to produce.dbarena follows three rules: every published result can be checked independently, comparisons are normalized for cost, and the methodology is public.Subscribe to the [dbarena newsletter](https://dbarena.com/?subscribe) to keep up with the latest comparisons and performance tracking over time.## Get started* Multigres: private alpha. [Request access](https://supabase.com/go/multigres-early-access).
* OrioleDB: create a new project and choose OrioleDB at project creation. Public beta. [Docs](https://supabase.com/docs/guides/database/orioledb).
* dbarena: public, at [dbarena.com](https://dbarena.com).