OrioleDB engine for PostgreSQL

@arundsharma @TigerDatabase It's 23, Claude is wrong. In OrioleDB, the MVCC header is 16 bytes, and the tuple header is 8 bytes (total is 24). But the 8-byte part can sometimes be skipped. In the future, we can work out cases when the MVCC header can be skipped. But we are yet concentrated on stability.

@TigerDatabase What does the overhead look like for @orioledb the table access method everyone is waiting for to exit beta? Right now at beta14. Claude thinks 8 bytes, not 23. Anyone measured it?

MVCC is one of the best things about Postgres. It's also costing you more than you think if your rows never change after insert. Every row in Postgres carries a fixed 23-byte header, plus padding, that tracks who created it, who deleted it, and whether the transaction committed. That machinery exists so concurrent readers and writers never block each other. It's elegant engineering, and for mixed read-write workloads, it earns every byte. But sensor data doesn't get updated. Log entries don't get edited. Financial ticks don't change after they land. If you're running an append-only workload, those bytes are infrastructure for a problem you don't have. At high ingest rates, they add up: a 1KB sensor reading actually writes 2.5-3.5KB to disk once you account for headers, indexes, and WAL records. Autovacuum still runs continuously, even when there's nothing to clean up, because Postgres triggers it on insert volume alone. None of this is a bug. It's an architecture built for a different workload pattern, doing exactly what it was designed to do. Recognizing the mismatch is more useful than trying to tune around it. @mattstratton from Tiger Data (creators of @TimescaleDB) walks through the per-byte accounting, the write amplification chain, and what changes when the storage model actually fits the workload. tsdb.co/xbt73lov

OrioleDB beta14 is published! 🎉 github.com/orioledb/oriol…

@michaelfreedman @kiwicopple Thank you for your interest! It actually reverts all the operations on the data pages using the undo log. This is very fast if you need to rewind to a recent state.

@kiwicopple This is really interesting, particularly like SQL as the control API! Does it actually undo operations via the WAL, or are you just resetting the state of the database (in which case, how do you deal with the actual data pages)?

OrioleDB is our next-gen storage extension for Postgres we just added a feature so that you can rewind your database to a specified timestamp

@kiwicopple I’ve been running a long running test for a year with OrioleDB, I’ve been impressed so far!

Supabase is working with the @orioledb team to develop a high-performance storage engine for Postgres and push the state of the art with a Postgres-first mindset

Scaling Postgres 383 is released! In this episode, we discuss the free availability of an OrioleDB patent, pgEdge going open source, pg_duckdb hitting 1.0 and methods resolve to slow order by limit queries: scalingpostgres.com/episodes/383-o… #Postgres #PostgreSQL

The best conf of the year is almost at full capacity! Secure your seat: select.supabase.com

Today we are making the @orioledb Patent freely available to the Postgres community Oriole is a storage extension for Postgres which uses Postgres' pluggable storage system. It's a drop-in replacement for Postgres' existing storage engine (Heap). Our north star is to upstream Oriole to be part of the Postgres source tree, developed and maintained in the open alongside the rest of Postgres (if the community want it!) We announced the acquisition of Oriole over a year ago. Since then, we have been working on cleaning up the legal structure and finalizing the asset transfers. We have wrapped up all legal activities, and we fully own US Patent 10,325,030 (“Durable multiversion B+-tree”). @supabase is making this Patent explicitly available to all Oriole users (including proprietary forks) in accordance with the open source license. Oriole benchmarks show that it is around 5.5x faster than the default storage engine (Heap):

Scaling Postgres 380 is released! In this episode, we discuss enhancements to Oriole DB, new Postgres releases, a logging guide and application framework frustrations: scalingpostgres.com/episodes/380-s… #Postgres #PostgreSQL

30 days later and we're now ingesting up to 500K logs/second x.com/kiwicopple/sta…

Alexander Korotkov: Ordered Insertion Optimization in OrioleDB postgr.es/p/7b4

@eatonphil PostgreSQL MVCC is not broken. It's a correct and complete implementation of one of the possible designs. There is nothing to fix within this design.

@orioledb Most of the OrioleDB posts, including this one, are about how to make Postgres flexible to allow completely different parallel implementations of MVCC. That's totally cool but not what I'm saying. I'm asking why didn't Postgres developers just fix the current MVCC themselves?

As many times as I've read the papers and blog posts critiquing Postgres's MVCC, while I can believe it, I don't get it. If someone has a good visual I'd appreciate it.

@eatonphil Please, check this. orioledb.com/blog/better-ta… Real alternative MVCC would require end-to-end redesign of the table AM API, the index AM API, and implementations. This is one of the things we're doing, pretty tough by itself.

Because I kind of get the sense that Postgres developers will do what makes sense until there are tradeoffs that are unclear. And I suspect the MVCC implementation is one of these with unclear tradeoffs. In which case I don't understand the critique.

new article from @ssougou on Postgres HA and how it will be handled in @multigres : multigres.com/blog/postgres-…

Alexander Korotkov: OrioleDB fastpath search postgr.es/p/79Y

New @orioledb release: we added TPC-C benchmarks so you can be the judge on the performance In case you're new to Oriole: it's a Postgres extension that replaces the default storage engine. GA coming soon.

@orioledb is about to get 20% faster

Joining Supabase For some time, I've been considering a Vitess adaptation for Postgres, and this feeling had been gradually intensifying. The recent explosion in the popularity of Postgres has fueled this into a full-blown obsession. As these databases grow, users are going to face a hard limit once they max out the biggest available machine. The project to address this problem must begin now, and I'm convinced that Vitess provides the most promising foundation. After exploring various environments, I found the best fit with Supabase. I’m grateful for how they welcomed me. Furthermore, their open-source mindset, fully remote work culture, and, most importantly, the empathetic leadership of @kiwicopple resonated with me. Now, it’s time to make this happen. Regarding PlanetScale You might wonder why I didn’t consider building this at PlanetScale. After nearly three years away, I've come to recognize that it’s a different company now, with its own priorities and vision. I had to draw a line. It required some introspection, but I finally shifted my perspective from "What should the co-founder of PlanetScale do?" to "What should the co-creator of Vitess do?". Once I framed the question this way, the answer became clear.

The tech stack I use to build my SaaS products making almost $7k+/mo: Frontend - @nextjs ($20/mo) Backend - @nextjs Database - @supabase ($30/mo) Authentication - @supabase Deployment - @vercel UI Kit - @chakra_ui / @shadcn State management - @tan_stack Customer Support - @crisp_im User feedback - @featuresvote Change logs - @featuresvote Sending emails - @resend AI assistant - @cursor_ai ($20/mo)