apps/www/_blog/2024-04-15-supabase-acquires-oriole.mdx
Oriole is a table storage extension for Postgres. It is designed to be a drop-in replacement for Postgres' existing storage engine.
The Oriole team are joining Supabase to:
Let's explore all of these below:
Oriole acts as a drop-in replacement for the default Postgres storage engine using the Table Access Method APIs:
create extension orioledb; -- enable the extension
create table posts (
id int8 not null,
title text not null,
body text not null,
primary key (id)
) using orioledb; -- Specify the storage format
The using clause might look familiar if you have used other storage engines in Postgres like Citus columnar, Hydra, ParadeDB, or zheap. These all use the Table Access Method API - a set of methods that provide pluggable storage.
The orioledb storage engine changes the representation of table data on disk. Its architecture is designed to take advantage of modern hardware like SSDs and NVRAM.
It implements MVCC, the feature that allows multiple connected users to see different versions of the data depending on when their transaction started, via an UNDO log rather than tuple versioning. Orioles architecture prevents bloat and provides several features and benefits:
We've written previously about Pluggable Storage: it gives developers the ability to use different storage engines for different tables within the same database. This system is available in MySQL, which uses the InnoDB as the default storage engine since MySQL 5.5 (replacing MyISAM).
Oriole aims to be a drop-in replacement for Postgres' default storage engine and supports similar use-cases with improved performance. Other storage engines, to name a few possibilities, could implement columnar storage for OLAP workloads, highly compressed timeseries storage for event data, or compressed storage for minimizing disk usage.
In version 12, PostgreSQL introduced support for pluggable storage with the goal of adding ZHeap - a previous effort to solve some shortcomings of Postgres' default storage format. We hope to contribute towards these efforts.
OrioleDB currently requires a set of patches to Postgres to expand on the type of features external storage engines extensions can implement. We remain committed to open source we'll work with the Oriole team and Postgres community with the goal of upstreaming patches so that Oriole can be used with any Postgres installation. We have no timeline for this, but it's safe to expect that it could be a few major Postgres versions away.
The Oriole storage engine's reduction in disk IO is significant enough that it unlocks performant databases backed by S3 compatible blob storage.
We've been working with the Oriole team for a few months to develop experimental support decoupled storage and compute:
<div className="video-container"> <iframe className="w-full" src="https://www.youtube-nocookie.com/embed/NO6xd1n9OKw" title="Decoupled storage and compute in Postgres" allow="accelerometer; autoplay; clipboard-write; encrypted-media; fullscreen; gyroscope; picture-in-picture; web-share" allowfullscreen /> </div>Local storage implements caching of the data most often accessed, ensuring good performance, and then synced with S3 asynchronously.
You can connect an empty Postgres instance to an s3 bucket (using an S3 loader utility). The Oriole roadmap includes the ability to connect multiple read-replicas to the same S3 bucket as leader.
Portability is a core principle at Supabase. Because Oriole requires a few minimal patch sets on top of Postgres, we will roll it out as an option for developers in the future. Over time we hope that it can become available for any Postgres installation and we will continue to work with Oriole and the Postgres community to make this happen.