OrioleDB for Self-Hosted Supabase: The Next-Gen Storage Engine

PostgreSQL is battle-tested and reliable, but its traditional heap storage has some well-known limitations—table bloat, vacuum overhead, and scalability bottlenecks under high-concurrency workloads. If you're self-hosting Supabase and pushing the limits of your database, OrioleDB might be worth your attention.

OrioleDB is a next-generation storage engine for PostgreSQL that Supabase acquired in 2024. It's designed to eliminate vacuum operations entirely, improve vertical scalability, and eventually support S3-backed "bottomless" storage. For self-hosters willing to experiment, it represents a glimpse into PostgreSQL's future.

What is OrioleDB and Why Should You Care?

OrioleDB is a drop-in replacement for PostgreSQL's default heap storage engine. Rather than modifying PostgreSQL's core, it uses the pluggable storage API—meaning you can use OrioleDB for specific tables while keeping traditional heap storage for others in the same database.

The key architectural differences that matter for self-hosters:

Index-Organized Tables: OrioleDB stores table data directly in the index structure. This eliminates the separate heap file, reduces I/O overhead, and dramatically improves primary key lookup performance.

Undo Log-Based MVCC: Instead of PostgreSQL's traditional approach of keeping old row versions in the table itself (which creates bloat requiring vacuuming), OrioleDB uses an undo log similar to Oracle. Old versions are stored separately and cleaned up automatically—no vacuum needed.

Lock-Free Page Reading: The traditional PostgreSQL buffer mapping system creates contention under high concurrency. OrioleDB eliminates these bottlenecks, improving vertical scalability on modern multi-core servers.

In benchmarks using TPC-C (a standard transactional workload), OrioleDB has shown 3.3x to 5.5x performance improvements over standard PostgreSQL heap storage.

Current Status: Beta, Not Production-Ready

Here's where honesty matters: OrioleDB is currently in public beta. The Supabase and OrioleDB teams are clear that it's recommended for "experiments, testing, benchmarking, etc., but is not recommended for production usage."

Current limitations you should know about:

B-tree indexes only: Vector indexes (HNSW) for pgvector aren't supported yet
No prepared transactions: Cross-database transactions involving OrioleDB tables won't work
No REINDEX CONCURRENTLY: You'll need to use regular REINDEX operations
Limited extension compatibility: Some PostgreSQL extensions may not work with OrioleDB tables

That said, for development environments, staging systems, or non-critical workloads where you want to evaluate the future of PostgreSQL, self-hosting OrioleDB with Supabase is a viable option.

Setting Up OrioleDB for Self-Hosted Supabase

There are three approaches to running OrioleDB with your self-hosted Supabase instance.

Option 1: Use Pigsty (Recommended for Production Exploration)

Pigsty is an enterprise-grade PostgreSQL distribution that bundles OrioleDB support with full observability. It's one of the three officially recognized self-hosting approaches in Supabase's documentation.

# Download and configure Pigsty with Supabase template
curl -fsSL https://repo.pigsty.io/get | bash
cd ~/pigsty
./configure -c supabase

# Deploy the stack
./deploy.yml
./docker.yml
./app.yml

Pigsty gives you the flexibility to choose different PostgreSQL kernels including PG 15-18 and OrioleDB, along with monitoring, high availability, and access to 510+ PostgreSQL extensions—far more than the 64 available on Supabase Cloud.

Option 2: Direct OrioleDB Docker Images

For quick experimentation, you can run OrioleDB directly using the official Docker images:

docker run --name orioledb-postgres \
  -e POSTGRES_PASSWORD=your_secure_password \
  -e POSTGRES_INITDB_ARGS="--locale=C" \
  -d -p 5432:5432 \
  orioledb/orioledb:latest-pg17

This approach works well for testing OrioleDB's performance characteristics before integrating it into a full Supabase stack.

Option 3: Supabase Cloud with OrioleDB Alpha

If you're using Supabase Cloud (not self-hosted), you can create a new project and select "OrioleDB Public Alpha" as your Postgres version. This is the easiest way to experiment, though it defeats the purpose if your goal is self-hosting.

Creating Tables with OrioleDB Storage

Once you have OrioleDB available, creating tables that use the new storage engine is straightforward:

-- Create a table using OrioleDB storage
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INT NOT NULL,
  order_date TIMESTAMP DEFAULT NOW(),
  total_amount DECIMAL(10, 2),
  status TEXT DEFAULT 'pending'
) USING orioledb;

-- Create an index (B-tree only for now)
CREATE INDEX idx_orders_customer ON orders (customer_id);

-- Regular PostgreSQL queries work as expected
INSERT INTO orders (customer_id, total_amount)
VALUES (1, 299.99);

In Supabase's OrioleDB image, OrioleDB is set as the default storage method, so standard CREATE TABLE statements will automatically use the new engine.

When OrioleDB Makes Sense for Self-Hosters

Consider experimenting with OrioleDB if you're dealing with:

High Write Workloads: Applications with frequent INSERT/UPDATE operations suffer most from vacuum overhead. OrioleDB's undo log approach eliminates this entirely.

Concurrency Bottlenecks: If you've tuned your PostgreSQL performance and still hit scalability limits on high-core-count servers, OrioleDB's lock-free architecture may help.

Table Bloat Problems: Even with proper autovacuum tuning, some workloads accumulate bloat faster than vacuum can clean it. OrioleDB makes this a non-issue.

Future-Proofing Evaluation: If you're building systems that will run for years, understanding where PostgreSQL is headed helps inform architecture decisions.

What's Coming: S3-Backed Bottomless Storage

The most exciting OrioleDB feature on the roadmap is S3 integration for what they call "bottomless storage." The architecture decouples compute from storage entirely—your database can scale storage infinitely via S3 while compute resources scale independently.

This matters for self-hosters because:

Storage costs drop significantly compared to provisioned SSDs
Disaster recovery simplifies since data lives natively in S3
Scaling becomes more flexible without capacity planning for disk

The S3 integration is still under development, but it represents Supabase's vision for a truly cloud-native PostgreSQL that remains self-hostable and vendor-neutral.

Trade-offs to Consider

OrioleDB isn't a silver bullet. Before investing time in integration:

Extension Compatibility: Many PostgreSQL extensions you rely on may not work with OrioleDB tables. Test your specific stack thoroughly.

Operational Maturity: The tooling, documentation, and community knowledge around OrioleDB is less developed than traditional PostgreSQL. When things break, debugging is harder.

Migration Complexity: Moving existing tables from heap to OrioleDB requires careful planning. You can't simply change storage engines on existing tables.

Backup Procedures: Your existing backup strategies may need adjustment since OrioleDB's internal data format differs from heap storage.

For most self-hosted Supabase deployments in 2026, sticking with traditional PostgreSQL heap storage remains the pragmatic choice. OrioleDB is worth watching and testing, but not deploying for critical workloads yet.

Getting Started Without Risk

If you want to evaluate OrioleDB without impacting your production self-hosted setup:

Spin up a separate test instance using the OrioleDB Docker image
Mirror your schema and load representative test data
Run your benchmark suite comparing heap vs. OrioleDB performance
Test your application code for compatibility issues
Evaluate operational aspects like backup, monitoring, and recovery

Supascale's one-click deployment makes it easy to manage multiple Supabase instances—you could maintain a production instance on standard PostgreSQL while experimenting with OrioleDB on a separate server.

The Bigger Picture

OrioleDB represents Supabase's long-term bet on making PostgreSQL competitive with purpose-built cloud databases while remaining fully open-source and self-hostable. The combination of no vacuum, better scalability, and eventual S3-native storage addresses the core complaints enterprise teams have about PostgreSQL at scale.

For self-hosters, this matters because it means the open-source option isn't standing still. You're not choosing between "easy but proprietary" and "open but limited"—the self-hosted path is actively improving.

Keep an eye on OrioleDB's progress toward GA (general availability), particularly the index access method bridge that will unlock vector index support. Once that lands, OrioleDB becomes viable for a much broader range of workloads including AI applications with pgvector.