Hacker News Reader

Comment by ctippett | Hacker News Reader

The article makes some convincing arguments and the benchmarks seem to corroborate their performance claims, but I don't understand the dichotomy between this proposed new storage engine (OrioleDB?) and PostgreSQL itself.

Besides the commercial motivations and wanting to profit from the innovations discussed in the article, is there any reason why this needs to be a whole new database marketed as OrioleDB versus contributing these improvements upstream?

View on HN

I'm seeing OrioleDB as a future engine for PostgreSQL. I'd like to see it as the default engine. However, the changes in OrioleDB are too big to be made incrementally. This is why I'm comparing the current PostgreSQL engine (with more than just heap, but many other subsystems as well) with OrioleDB.

Just curious, are you ukrainian?

Never thought I would see a fellow ukrainian rewriting my fav db.

Curious if you could share further roadmap. Potential interesting directions: 1. plans for integration with object store ala neon?

2. Columnar?

3. Async-io oriented redesign

4. Interesting new features ala subscriotions to table changes

5. Zero copy client bindings

Are there plans to build flashback-like functionality on top of Oriole DB? Being able to query data "as of xid" would be a great feature.

Alexander Korotkov (OrioleDb author) idea, - based on his Postgres committer experience, I believe, - is that these changes are way too big to be ever accepted upstream, hence separate engine. More info https://www.socallinuxexpo.org/sites/default/files/presentat..., see esp. slides 9-11

These changes are way too big to integrated into postgresql's engine itself. It fundamentally changes how MVCC is done.

Reply on news.ycombinator.com