I am super bullish on OrioleDB. It really seems like the next logical progression for scaling Postgres for 99% of all databases out there. I have been following their development for a while and running benchmarks to see if their performance claims are legitimate, and so far it has been amazing
Thanks for verifying the benchmarks. We’re close to a full RC, aiming for December
Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us
I assume you get this a lot, but how much patching is left in PG 18?
We are tracking the patches here:
https://www.orioledb.com/docs#patch-set
The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then it should be simpler for anyone to write their own Storage extensions.
I think (correctly) it will take a lot longer to upstream the extension - the PG community should take a “default no” attitude with big changes like this. Over time we will prove its worthiness (hopefully beyond just supabase - it would be good to collaborate with other Postgres providers)
OK, so basically no big change with PG 18, and for the time being, one needs to basically your own Postgres?
Would be really nice with a pgdg package, as this is definitely the kind of thing I would want to test in a separate cluster :-)
Based on the README [0] and discussion [1] it seems like it might especially shine on high-write-volume workflows, with the implementation of anti-bloat measures. Do you have a sense for whether it would shine even further where those rows have large text/JSONB fields that might be TOASTed?
And more generally, curious if you have any sense for what might make up the "1%" of workflows this wouldn't be advisable for? Any downsides to be aware of?
[0] https://github.com/orioledb/orioledb?tab=readme-ov-file#orio...
[1] https://news.ycombinator.com/item?id=30462695 (2022)
I haven't explicitly tested how it handles TOASTed column's, but since there is an upcoming RC I will try it out next time. I don't generally like using JSONB/text columns for very large rows as they have other performance problems on the DB like causing lots of WAL write overhead.
In term of other workloads it might not be great for, all my testing has shown a great improvement in every workload I have thrown at it.
OrioleDB looks interesting but the with the storage changes, the issue will be the compatability with other extensions. pg_search (paradedb), timescale come to mind.
We have seen this issue with YugabyteDB, and their integration off RocksDB as the storage engine for postgresql.
As far as I know, you can run heap and orioledb tables side by side in the same system, so I don’t see a problem using heap-based extensions like timescale together with orioledb. ( of course timescale doesn’t support OrioleDB storage yet, but they can run in parallel. )
and many extensions (e.g. postgis) already work fine with OrioleDB storage.