OrioleDB — Cloud-Native Storage Engine for PostgreSQL

Introduction

OrioleDB is a table access method extension for PostgreSQL that replaces the heap storage engine with a modern design based on undo logging and copy-on-write checkpointing. It solves long-standing Postgres pain points like table bloat, VACUUM overhead, and write amplification while remaining fully SQL-compatible.

What OrioleDB Does

• Replaces the default Postgres heap storage with a no-VACUUM table access method
• Eliminates table bloat by using undo logs instead of multi-version heap tuples
• Reduces write amplification through copy-on-write checkpointing (no full-page writes in WAL)
• Provides row-level WAL for lower I/O overhead on write-heavy workloads
• Supports S3-compatible object storage as a native storage backend for cloud deployments

Architecture Overview

OrioleDB implements a Postgres table access method that stores data in a dual-pointer B-tree structure instead of the traditional heap. Dead tuples are tracked via an undo log and reclaimed automatically without VACUUM. Checkpointing uses a copy-on-write mechanism that avoids the full-page write penalty of the standard Postgres WAL. The storage layer abstracts block access so that pages can be stored on local disk or in S3-compatible object storage.

Self-Hosting & Configuration

• Run the official Docker image, which packages PostgreSQL with OrioleDB pre-built
• Build from source against a patched PostgreSQL (patches are included in the repository)
• Enable per-table by specifying USING orioledb in CREATE TABLE statements
• Mix OrioleDB and standard heap tables in the same database
• Configure S3 storage backend via postgresql.conf parameters for cloud-native deployments

Key Features

• No VACUUM required; dead tuples are cleaned up automatically via undo logging
• Reduced write amplification saves SSD lifespan and lowers cloud storage costs
• S3-native storage enables disaggregated compute and storage architecture
• Drop-in compatibility with standard PostgreSQL SQL, extensions, and tooling
• Per-table opt-in allows gradual migration of high-churn tables

Comparison with Similar Tools

• Standard PostgreSQL heap — The default storage engine that OrioleDB replaces; requires VACUUM and suffers from bloat on write-heavy workloads
• InnoDB (MySQL) — MySQL engine with undo logging (similar concept), but tied to the MySQL ecosystem
• Neon — Serverless Postgres with disaggregated storage, but modifies the entire Postgres stack rather than offering a per-table access method
• AlloyDB (Google) — Managed Postgres-compatible service with a custom storage layer, but proprietary and not self-hostable
• CockroachDB — Distributed Postgres-compatible database; different scope focused on horizontal scaling rather than single-node storage efficiency

FAQ

Q: Can I use OrioleDB tables alongside standard Postgres tables? A: Yes. OrioleDB is a table access method, so you can choose it per table. Standard heap tables continue to work normally in the same database.

Q: Does OrioleDB eliminate the need for VACUUM entirely? A: For OrioleDB tables, yes. The undo log mechanism reclaims dead tuple space without a separate VACUUM process.

Q: Is OrioleDB production-ready? A: OrioleDB is under active development. It is used in production by some organizations, but the maintainers recommend testing thoroughly for your specific workload before deploying broadly.

Q: What Postgres versions does OrioleDB support? A: OrioleDB tracks recent PostgreSQL major versions. Check the repository for the current supported version matrix.

Sources

• https://github.com/orioledb/orioledb
• https://orioledb.com