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
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
thanks for running the benchmarks, it helps to have external parties verifying the progress
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.
apavlo•1d ago
Source: https://db.cs.cmu.edu/papers/2017/p781-wu.pdf (see Table 1 + Section 6.1)
_joel•1d ago
rolls off the tongue.
mattashii•9h ago
The CMU paper indicates the logical keys are either TupleID or Primary Key, while the bridged index is actually a TupleID that resolves to a Primary Key, which resolves to the actual tuple - one more level than indicated by 6.1's explanation of logical pointers.