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.

What is OrioleDB?​

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.

What’s New in OrioleDB?​

Building on this foundation, recent releases have introduced several user-facing enhancements:

• Support for non‑B-tree index types on OrioleDB tables.
• Support for rewinding recent changes in the database.
• Support for tablespaces.
• fillfactor support for OrioleDB tables and indexes.
• orioledb_tree_stat() 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.

Performance improvements​

Alongside these user‑facing additions, significant performance improvements have been made:

Storage and Transactional Efficiency​

• 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

Query and Index Performance​

• 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.

Benchmarks​

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

Benchmark Infrastructure​

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.

Benchmark 1: go-tpc​

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:
  1. 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
  

  1. 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>
  

  1. 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:

Benchmark 2: sysbench​

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.

Benchmark 3: OLTP​

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.

Get started with OrioleDB​

The best way to get started with OrioleDB is to use the docker image provided:

docker run -d --name orioledb -p 5432:5432 orioledb/orioledb