Supabase's OrioleDB storage engine reaches public beta
OrioleDB swaps Postgres heap storage for an undo log, and early benchmarks show up to 1.8x more transactions once data outgrows memory. Not for production yet.
Supabase moved OrioleDB out of alpha and into public beta on 28 October, available on every plan from project creation. OrioleDB is an open-source Postgres storage engine that swaps the default heap, with its dead tuples and buffer mapping, for an undo log, 64-bit transaction IDs and copy-on-write checkpoints. This beta ships OrioleDB beta19 on Postgres 17.11.
Supabase’s own benchmarks, run on a workload it says isn’t comparable to published TPC-C results, found about 1.8x more transactions per minute than heap storage on an 8XL instance once data outgrows memory, reaching 113,850 transactions per minute. At Small instance size, heap actually came out ahead. It’s billed the same as standard Postgres, with no separate pricing tier.
The beta comes with real limits: no point-in-time recovery, no production SLA, and you choose OrioleDB at project creation with no way to switch an existing project over or back later. pgvector’s HNSW index runs through an experimental bridge rather than natively, and commands like CLUSTER and VACUUM FULL don’t work on OrioleDB tables yet.
Why it matters: if you run a Postgres workload that updates rows heavily and outgrows memory, this is a concrete, billed-the-same option to test, not a hypothetical. The caveats are specific enough to know exactly what not to rely on yet: no PITR, no HNSW speedup, no self-hosting.