planetscale/orioledb

OrioleDB is a new storage engine for PostgreSQL, one of the most popular database systems in the world. Think of it as a replacement "filing system" for how Postgres stores and manages your data. The goal is to solve long-standing pain points, like performance bottlenecks and maintenance headaches, that have plagued Postgres as workloads have grown, especially in cloud environments. Right now it's in public beta, meant for experiments and benchmarking rather than production use. At its core, the project rethinks how Postgres handles data behind the scenes. Instead of relying on older mechanisms that can slow down modern servers with many CPU cores, it uses a lock-free approach to reading data and eliminates legacy bottlenecks. Old versions of data, normally left behind and cleaned up later, are moved to a separate "undo log," which means the system can reclaim space almost immediately. This removes the need for routine maintenance tasks like vacuuming, which are a common cause of performance dips and outages in standard Postgres setups. The target audience is teams running large or demanding Postgres workloads who've hit scaling limits or maintenance burdens. For example, a SaaS company whose database slows down during heavy garbage collection cycles, or an engineering team that wants to scale vertically on modern multi-core servers without hitting locking bottlenecks. It's also designed with distributed systems in mind: its write-ahead log is built to support active-active multi-master replication, which means multiple databases could eventually accept writes simultaneously and stay in sync. Getting started requires a patched version of Postgres (16 or 17), and you can run it via Docker or build from source. Once enabled, you simply add USING orioledb when creating a table to use the new engine. It only supports ICU, C, or POSIX collations, so your database locale needs to match. The README doesn't go into deep detail on real-world performance benchmarks, but the design choices suggest clear tradeoffs: you gain modern hardware optimization and reduced maintenance, at the cost of needing a non-standard Postgres build and living with beta-status maturity.