hey hn, supabase ceo here<p>we've been fans of Oriole for a while now and have been long-time supporters<p>in case you're jumping straight to the comments: OrioleDB is a table storage extension for Postgres. it acts as a drop-in replacement for the default postgres storage engine using the Table Access Method APIs (pluggable storage). the 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 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.<p>one caveat: it requires several patches to the postgres core to expand on the type of features external storage engines extensions can implement. for this reason it could be a while before you see this land as a default engine on supabase. we will probably make it available as an option for customers who want to experiment - no timeline is decided yet.<p>finally, we have been working with the team on decoupled storage and compute [0]. this is experimental but promising, especially with some recent advances in S3 (specifically Express One Zone [1]). we have a demonstration in the blog post.<p>i'll message Alexander in case there are any technical questions<p>[0] <a href="https://github.com/orioledb/orioledb/blob/main/doc/usage.md#s3-database-storage-experimental">https://github.com/orioledb/orioledb/blob/main/doc/usage.md#...</a><p>[1] <a href="https://aws.amazon.com/s3/storage-classes/express-one-zone/" rel="nofollow">https://aws.amazon.com/s3/storage-classes/express-one-zone/</a>
> It implements row-level WAL (Write-Ahead Log) and a non-persistent undo log. This significantly reduces IO operations for write transactions.<p>What is the downside of doing this? I assume there is a tradeoff?