Supabase's OrioleDB beta swaps Postgres storage. The benchmarks are its own

Supabase has put OrioleDB, a new storage engine for Postgres, into public beta. Supabase says it is not ready for production. The design targets a familiar chore: cleaning up old copies of rows. It is also built for speed, and Supabase's benchmark reports throughput gains. Whether the cleanup chore costs your team enough to matter is something to check, not assume.

What Supabase announced

OrioleDB is available on every Supabase plan. It is an open-source storage engine for Postgres. Postgres is the database many firms use for orders, accounts and stock. Supabase announced it at its Supabase Select event, alongside Multigres and DBArena.

Users choose it when they create a project. Supabase says billing matches standard Postgres. It also says the beta is for testing and has no SLA. Work on the engine began in 2021, and Supabase says its creators are on the Supabase team.

Why busy Postgres tables need upkeep

By default, Postgres keeps rows in a structure called the heap. Supabase explains that changing a row does not overwrite it. Postgres adds a fresh copy and the previous copy stays in the table. That leftover copy is called a dead tuple. Deletes leave them too.

Indexes record where a row physically sits. So each new version generally has to be added to all of the table's indexes. That includes indexes on columns the update never touched.

A background job called autovacuum runs VACUUM to clear the old versions. Supabase says autovacuum can fall behind on tables with many updates or deletes. The result is bloat. Storage swells beyond the real data, and queries slow down because they have more pages to read. Teams respond with per-table settings, manual VACUUM runs or rebuild tools such as pg_repack.

Postgres also uses 32-bit transaction IDs, which wrap around. Supabase says a VACUUM that lags far enough can leave Postgres refusing new writes. Supabase gives no figure for how often this happens.

How OrioleDB changes the design

OrioleDB plugs in through the Table Access Method. This is the hook Postgres offers for swapping storage engines. Supabase says apps keep their connection strings, Auth, Row Level Security rules and client libraries.

The first change is an undo log. OrioleDB saves the earlier version of a changed row in a separate log, and the log is reclaimed automatically. Supabase says that in most cases tables do not accumulate dead tuples, so VACUUM has nothing to clean. It gives no measurement of bloat or of engineering effort saved.

The second is 64-bit transaction IDs on OrioleDB tables. Supabase says these do not wrap around. The 32-bit limit still applies to system catalogs and to any heap tables.

The third is storing rows inside the primary key index. A lookup by key touches one structure, not two. Secondary indexes refer to the primary key. An update therefore touches only the indexes whose columns changed.

Supabase also describes page reads without locks and no contention on Postgres's shared buffer mapping. It adds checkpoints that write only changed data.

What the benchmark shows, and what it does not

Supabase ran the test on DBArena, its own benchmark site for hosted Postgres. The workload is derived from TPC-C, a standard order-processing test. Supabase says the results cannot be compared with official TPC-C figures. The comparison covered Supabase's standard Postgres, Supabase running OrioleDB, Amazon RDS and Google Cloud SQL. It used seven machine sizes and two scenarios, one where data fits in memory and one where data is four times larger. Supabase says the code, method and raw results are public.

In the larger-than-memory case, Supabase says OrioleDB gave the most throughput per dollar at every size. On the 8XL machine, with 32 vCPU and 128 GiB of RAM, it handled about 1.8 times the transactions per minute of Supabase's heap storage. That came to 113,850. On the Small size, Supabase reports about 46% more throughput per dollar.

With data that fits in memory, the lead narrows. Supabase puts OrioleDB roughly 13% above heap storage on Large and roughly 29% above on 8XL. On Small, heap storage did better.

The benchmark does not isolate the effect of dead-tuple cleanup. The gains may come from the undo log. They may equally come from rows stored in the index, lock-free reads or lighter checkpoints. Supabase also says OrioleDB helps with larger-than-memory data, many connections and primary-key lookups, so those could contribute too. The source gives no per-table results.

Supabase expects the biggest gain on tables that are rewritten or emptied often. Its examples are tables tracking order status, stock levels, background jobs and user sessions, where heap storage builds the most bloat. It also names data larger than memory. This is a vendor testing its own product. Supabase itself advises benchmarking your own workload.

Limits to know before a trial

Read-mostly workloads that fit in memory should see a smaller difference. Workloads using pgvector HNSW indexes, often used for AI search, may see no gains yet. Those indexes run through an experimental bridge.

The engine is picked when a project is created. An existing project cannot switch to it, and a project cannot switch back. There is no Point-in-Time Recovery, and restoring a backup to a new project is not available. CLUSTER and VACUUM FULL do not work on its tables. Some extensions are missing, and it is not in the self-hosted Supabase stack yet.

One more limit matters for busy systems. By default, a SERIALIZABLE transaction takes a lock on each table it touches. The orioledb.serializable setting changes this. A team that relies on that isolation level should test it early.

What to ask your team

Start with cost. Which tables are updated or deleted most? How much engineering time goes to autovacuum tuning or table rebuilds? The answers show whether the problem OrioleDB targets is yours.

Then ask about risk. Can we test a copy of a real workload on a non-production project? Which of our extensions and index types are unsupported? Do any of our transactions use SERIALIZABLE? Can we live without point-in-time recovery during a trial?

The design targets two things: less cleanup on frequently updated tables, and higher throughput at high concurrency and with data larger than memory. Whether either holds for your tables is a claim to test, not assume.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Supabase.