top | item 45196733

(no title)

dkhenry | 5 months ago

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

https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N

discuss

order

kiwicopple|5 months ago

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

Sesse__|5 months ago

I assume you get this a lot, but how much patching is left in PG 18?

btown|5 months ago

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)

dkhenry|5 months ago

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.

benjiro|5 months ago

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.

pella|5 months ago

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.