Supabase opens OrioleDB Postgres storage engine to public beta

OrioleDB is now in public beta on every Supabase plan and is billed the same as standard Postgres. Compute and disk resizing, read replicas, Postgres upgrades and scheduled backups all work. Supabase says it is not ready for production yet.

OrioleDB replaces Postgres's heap through the Table Access Method, so connection strings, Auth, Row Level Security and client libraries stay the same. Updates and deletes write previous row versions to an undo log that is reclaimed automatically, so tables usually do not build up dead tuples for VACUUM to clean. Rows are stored inside the primary key index, and tables use 64-bit transaction IDs.

In benchmarks derived from TPC-C run on DBArena, Supabase reports that with data larger than memory, OrioleDB had the highest throughput per dollar of any tested product at every compute size. On an 8XL instance it reached 113,850 transactions per minute, about 1.8x heap storage. When data fits in memory the gap is smaller, and heap was ahead at the Small size.

Agent backends that constantly update rows, such as job queues, session data or order status, are the workloads where OrioleDB may reduce bloat and the need for manual autovacuum tuning. Supabase recommends benchmarking your own workload before relying on it.

Plan around the beta limits: there is no point-in-time recovery, CLUSTER and VACUUM FULL do not work on OrioleDB tables, and pgvector HNSW and other non-B-tree indexes run through an experimental bridge. You also cannot add OrioleDB to an existing project later or use it together with Multigres.