Supabase Opens OrioleDB to Paid Projects, Not Production

Supabase moved OrioleDB, its replacement for Postgres’s default heap storage, into public beta on Oct. 1, open to Pro, Team and Enterprise projects. The same changelog entry tells customers not to run it in production: “Public Beta is for testing. We don’t recommend OrioleDB for production workloads yet, and it has no SLA” (Supabase changelog, Oct. 1, 2026).

OrioleDB projects are billed the same as standard Postgres projects. Free-tier projects can’t use it. Supabase said existing alpha projects are unaffected.

What it changes

OrioleDB is a storage engine for Postgres. Supabase’s Oct. 2 Select 2026 post, written with OrioleDB co-creator Alexander Korotkov, says it removes table bloat, VACUUM overhead and transaction ID wraparound, which come from the 32-bit transaction IDs in heap storage. It claims up to 1.8x higher throughput than heap in TPC-C-derived benchmarks published on dbarena.com. Those are Supabase’s own numbers, and the post doesn’t give the instance size or date.

During the beta, you pick OrioleDB under advanced configuration when you create a project. The Select post also says a single project can mix engines per table, using USING orioledb or USING heap.

What’s missing

The changelog lists the gaps. Some decide whether a team can use it at all:

• Point-in-time recovery isn’t available.
• Backups can’t be restored to a new project.
• Non-B-tree indexes, including pgvector HNSW, run through an experimental bridge.
• The plv8, plls, plcoffee and timescaledb-apache extensions are missing.

The build is OrioleDB beta18 on Postgres 17.11. Resizing, pause and restore, version upgrades, read replicas and scheduled backups work. Locally, the CLI no longer needs the --experimental flag. Run supabase init --use-orioledb on CLI v2.119.0 or later.

Key Takeaways

• OrioleDB is in public beta on Pro, Team and Enterprise as of Oct. 1, 2026, billed like standard Postgres.
• Supabase says not to use it in production, and there is no SLA.
• No PITR and no restore to a new project in the beta.
• The 1.8x throughput claim is Supabase’s, from benchmarks it published itself.

The take

Charging for a beta that Supabase itself says to keep away from production is a bet that teams will test it on real schemas now. That’s reasonable, and it’s also the reason to read the gap list first. A database without PITR is a hard sell for anything you can’t rebuild from scratch. Use it on a staging copy, run your own workload before believing 1.8x, and check whether your extensions made the cut. If you depend on pgvector HNSW or TimescaleDB, wait.