Cannot wait for OrioldeDB to reach General Availability. Postgres needs options for open-source separation of storage and compute.
dkhenry · 19h ago
OrioleDB isn't a separation of storage and compute, its a more efficient storage engine for Postgres to replace the existing HEAP engine. This is like how in MySQL we could swap MyISAM for InnoDB and eventually RocksDB.
I did some benchmarks on it previously to show how much of an improvement it gives over the stock HEAP engine
EDIT: correct link to the public dashboard below, thanks for the heads up @kiwicopple
Is the need for Oriole negated by using a system that separates storage from compute like Neon, Xata?
tudorg · 13h ago
Answering on behalf of Xata, it is orthogonal. I'm curious to try out Oriole on our platform when I get some time.
nikita · 13h ago
(Neon CEO)
Not really. OrioleDB solve the vacuum problem with the introduction of the undo log. Neon gives you scale out storage which is in a way orthogonal to OrielDB. With some work you can run OrioleDB AND neon storage and get benefits of both.
akorotkov · 10h ago
> OrioleDB solve the vacuum problem with the introduction of the undo log.
Way more than just this!
> With some work you can run OrioleDB AND neon storage and get benefits of both.
This would require significant design work, given that significant OrioleDB benefits are derived from row-level WAL.
kiwicopple · 18h ago
fwiw I couldn't access your airtable link, but I found this one online:
"Bridged Indexes" is a non-standard term. These are just secondary indexes using logical pointers with a mapping index. IIRC, Oracle, Hana, and HyPer do the same thing.
I did some benchmarks on it previously to show how much of an improvement it gives over the stock HEAP engine
EDIT: correct link to the public dashboard below, thanks for the heads up @kiwicopple
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
https://www.orioledb.com/docs/usage/decoupled-storage
Not really. OrioleDB solve the vacuum problem with the introduction of the undo log. Neon gives you scale out storage which is in a way orthogonal to OrielDB. With some work you can run OrioleDB AND neon storage and get benefits of both.
Way more than just this!
> With some work you can run OrioleDB AND neon storage and get benefits of both.
This would require significant design work, given that significant OrioleDB benefits are derived from row-level WAL.
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
thanks for running the benchmarks, it helps to have external parties verifying the progress
Althoug with them being recently acquired by Databricks it remains to be seen how the open source version will fare.
This is unrelated to NeonDB. OrioleDB has been acquired by Supabase. https://supabase.com/blog/supabase-acquires-oriole
Source: https://db.cs.cmu.edu/papers/2017/p781-wu.pdf (see Table 1 + Section 6.1)
rolls off the tongue.