Since our last public update, OrioleDB has continued to evolve with a series of new releases. These updates refine the core engine, extend functionality, and improve performance across a range of workloads. Together, they move us closer to a beta release and lay the groundwork for broader adoption.
OrioleDB is a PostgreSQL storage extension that implements a custom Table Access Method as a drop‑in replacement for the default Heap storage engine. It is designed to address scalability bottlenecks in PostgreSQL’s buffer manager and reduces the WAL, enabling better utilization of modern multi-core CPUs and high‑performance storage systems.
By rethinking core components such as MVCC, page caching, and checkpoints, OrioleDB improves throughput and predictability in transactional workloads without altering PostgreSQL’s user-facing behavior.
Building on this foundation, recent releases have introduced several user-facing enhancements:
Support for non‑ B-tree index types on OrioleDB tables.
index types on OrioleDB tables. Support for rewinding recent changes in the database.
Support for tablespaces.
fillfactor support for OrioleDB tables and indexes.
support for OrioleDB tables and indexes. orioledb_tree_stat() SQL function for space utilization statistics.
SQL function for space utilization statistics. Support for tables with more than 32 columns.
These additions improve OrioleDB/PostgreSQL compatibility and provide more flexibility for workloads with diverse schema and indexing requirements.
Alongside these user‑facing additions, significant performance improvements have been made:
Sparse file support for more efficient storage allocation.
Separation of row‑level and page‑level undo logs.
Optimizations to avoid undo records for insertions into tables created by the same transaction
Custom scan node for primary key lookups, reducing redundant index searches.
Faster B-tree inner page navigation for improved index performance.
To assess the impact of these changes, we benchmarked OrioleDB against PostgreSQL’s default Heap storage engine using TPC-C style workloads with go-tpc and sysbench . These tests measure CPU and IO scalability under mixed read‑write conditions and evaluate how OrioleDB’s architecture performs in transactional workloads.
TPC-C is a standard benchmark for measuring how well databases handle high-throughput online transaction processing (OLTP). The test uses a database with 10 tables and includes five types of transactions:
NewOrder – for creating new orders
Payment – for processing payments
OrderStatus – for checking order status
Delivery – for handling deliveries
StockLevel – for analyzing inventory
We’ve run all of these instances on a Supabase 2XL Instance using io2 storage unless otherwise specified. Postgres configuration options use Supabase’s defaults.
The instance used for running the load test was located in the same AWS region (but in an different AZ) as the Supabase database to reduce the side effects of network latency, and to keep the scenario realistic.
We ran three different tools to assess Oriole beta12: go-tpc, sysbench, and OLTP.
go-tpc is a Go-based TPC-C benchmark by PingCAP. It prioritizes performance and ease of deployment. The goal of go-tpc is a lightweight, scalable benchmarking tool for modern distributed databases.
Run the test yourself Setup: 10,000 warehouses 1TB of data 1,000,000,000 rows in stock table 300,000,000 rows in customer, order, history tables Instructions: Prepare the database ./gotpc tpcc --warehouses 10000 prepare -T 100 -d postgres -U postgres -p 'password' -D postgres -H db.ref.supabase.com -P 5432 --conn-params sslmode=disable --no-check
Run the benchmark multiple times ./gotpc tpcc --warehouses 10000 run -d postgres -U postgres -p 'password' -D postgres -H db.ref.supabase.com -P 5432 --conn-params sslmode=disable -T <20,50,100,200,400> --time <100s,300s,1800s>
aggregate the results, calculate average numbers of tpmC (transactions-per-minute-C)
Results:
This TPC-C benchmark uses transactions-per-minute-C (tpmC) to measure the throughput of a system. This measurement is based on the number of NewOrder transactions a system can handle per minute:
Instance Postgres (HEAP) OrioleDB large 6,155 7,539 xl 11,129 18,390 2xl 12,812 25,786 4xl 17,392 31,844 8xl 37,577 84,770 12xl 56,830 116,564 16xl 83,653 218,716
sysbench is a Lua-based multi-purpose benchmark tool. Includes oltp_read_write, oltp_read_only, etc., which simulate OLTP workloads. The goal is general performance testing of transactional workloads, not strict TPC-C compliance.
Run the test yourself Setup: A TPCC data set generated with TABLES=20 and SCALE=250 500GB of data 64 connections Instructions: You can replicate the data following these instructions.
Results:
Postgres with OrioleDB averaged ~19,000 QPS. Postgres with Heap averaged ~9,500 QPS. With gp3 storage we observed ~8500 QPS for Postgres with Heap.
p99 Latency 32 threads: 64 threads:
The OLTP benchmark tends to be more read-heavy, and it helps to get insights into the performance for this type of workloads.
Run the test yourself Setup sysbench OLTP data set generated with TABLES=10 and SCALE=130000000 300GB of data 64 connections Instructions: Using the standard sysbench tool and the oltp_read_only benchmark. You can find instructions for replicating this benchmark here.
Results:
The Supabase Postgres database with OrioleDB averaged ~37,000 QPS. Standard Supabase database with Heap averaged ~32,000 QPS. As we can see even with OLTP workloads Oriole can provides noticeable performance gains, outperforming other Postgres providers, even without locally attached SSD disks.
p99 Latency 32 threads: 64 threads:
The best way to get started with OrioleDB is to use the docker image provided: