OrioleDB beta15 and beta16: stability, testing, and replication hardening | OrioleDB

Skip to main content<br>The beta15 and beta16 cycles together cover roughly four months of work on OrioleDB. Where previous releases introduced headline features such as non-B-tree index support, tablespaces, and undo-based rewind, these two releases are deliberately focused on stability, correctness, and test coverage . The goal is simple: make every existing feature work reliably under real-world conditions, especially replication, recovery, and concurrent workloads.

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 WAL subsystem, enabling better utilization of modern multi-core CPUs and high-performance storage.

By rethinking core components such as MVCC, page caching, and checkpoints, OrioleDB improves throughput in transactional workloads without altering PostgreSQL's user-facing behavior.

Why a stability-focused stretch?​

After several feature-heavy cycles, the OrioleDB team shifted focus to hardening the engine against edge cases exposed by broader adoption and more aggressive testing. The combined beta15+beta16 work contains numerous bug fixes spanning recovery, physical and logical replication, checkpointing, undo management, bridge indexes, page pool, and B-tree internals, plus separate fixes for various races during concurrent operations. Rather than adding new surface area, these releases make the existing surface area solid.

A new approach to testing​

The most impactful change in this period is the dramatic expansion of test coverage. Instead of relying on existing and new OrioleDB-specific tests, we adopted a fundamentally different strategy: use PostgreSQL itself as the test source and predictor .

Running PostgreSQL's own tests on OrioleDB tables​

A major milestone is running the standard PostgreSQL regression test suite with OrioleDB as the default table access method. This means the same INSERT, SELECT, UPDATE, MERGE, COPY, window functions, CTEs, partitioning, grouping sets, domain types, row types, generated columns, and dozens of other SQL features tested by the PostgreSQL community are now continuously validated against OrioleDB storage.

The tests are filtered by a purpose-built diff-filtering tool that accounts for known, expected differences in OrioleDB's output: slightly different plan shapes, storage-level details, and similar cosmetic divergences. The result is a continuous signal: if a standard PostgreSQL behavior breaks under OrioleDB, CI catches it immediately.

PostgreSQL's isolation tests are included as well, verifying that concurrent transaction behavior (eval-plan-qual and friends) matches expectations when the storage layer is OrioleDB. PostgreSQL's own recovery tests have likewise been brought into the CI pipeline, exercising restart, crash-recovery, and replay paths that earlier OrioleDB-specific suites only touched indirectly.

This single change surfaced more compatibility issues in a few weeks than months of dedicated testing. Many of the fixes in this period: hashing, generated columns, domain types, TOAST overflow handling, ALTER TABLE edge cases, contradictory NULL scan keys, SAOP/IN scans on PKs with reordered columns were discovered by simply running PostgreSQL's own tests and reading the diffs.

Verifying replication correctness automatically​

Running tests on a single primary node is necessary but not sufficient. As with any Postgres cluster, everything under the Oriole storage engine must also replicate correctly: every row written on the primary must appear identically on the replica after recovery.

We introduced automated primary/replica data comparison as part of the CI process. After running the full regression and isolation test suites, the pipeline now runs all tests with a replica attached , exercising the replication path alongside the primary path, compares the replica's data and meta state to the primary's data, table by table, and fails if any divergence is found.

This catches a class of edge case bugs that are invisible on a single node: incorrect WAL records for DDL operations, bridge index state propagation anomalies, undo cleanup races that can corrupt replica-side pages, and tablespace metadata not surviving a replica restart. Several of the replication fixes shipped in these releases were found exclusively through this mechanism.

A complementary test verifies that after a replica is stopped and restarted, its indexes are rebuilt correctly and queries return the same results as on the primary, targeting the subtle class of bugs where in-memory state diverges from on-disk state during recovery.

Crash consistency testing with dm-log-writes​

We also introduced crash consistency testing built on the Linux dm-log-writes device-mapper target. The...