OrioleDB – solving some PostgreSQL wicked problems

Wow, this looks to potentially save my team hundreds of hours of work. This product and its aims are nearly 1:1 with a massive Postgres extension project we were to start developing next quarter. Who should I get in touch with to see about us contributing instead to Oriole? I would love for our team to support the project with man hours and possibly financial support as well, as it seems this will accelerate our project significantly.

This is exciting:<p>&gt; ...This log architecture is optimized for raft consensus-based replication allowing the implementation of active-active multimaster.<p>I&#x27;m a developer but manage 2 PostgreSQL instances each with an async replica. I also manage 1 three-node CockroachDB cluster. It&#x27;s night and day when it comes to any type of ops (e.g. upgrading a version). There&#x27;s a lot of reasons to use PostgreSQL (e.g. stored procedures, extensions, ...), but if none of those apply to you, CockroachDB is a better default.<p>I just finished interviewing someone who went into detail about the difficulty they&#x27;re having doing a large scale migration or a mission critical large PG cluster (from one DC to another)..it&#x27;s a multi-team, year long initiative that no one is comfortable about.<p>In my experience, PG is always the most out-of-date piece of any system. I still see 9.6 here and there, which is now EOL.

&gt; PostgreSQL 14 with extensibility patches,<p>can you elaborate on these patches? Have you worked on any parser-level hooks? I&#x27;m building an extension on PG, and have been trying to extend the parser without touching PG&#x27;s tree, but it looks impossible at this point.

That&#x27;s amazing! Thanks for making this open source.<p>Could this be extended to support temporal (and Bitemporal) tables? Some storage level optimizations could benefit performance and easy of use for use cases temporarily is important, like financial services systems.<p>Thanks

&gt; Reduced maintenance needs. OrioleDB implements the concepts of undo log and page-mergins, eliminating the need for dedicated garbage collection processes. Additionally, OrioleDB implements default 64-bit transaction identifiers, thus eliminating the well-known and painful wraparound problem.<p>I love this, no more vacuums?

Sounds really exciting. My wife noticed me reading the notes with such intent she asked me what I was reading.

Finally someone tackling the real problems that everyone glosses over when gushing about postgres. Bravo! This is a really excellent project.

How does this compare to zheap? I believe zheap made some similar design choices (undo based and avoiding the wraparound problems), though the replication features seem unique to oriole.

This is a bit of a digression, but since this topic attracted a lot of eyes interested in Postgres and databases…<p>Is there any hope of improvements to database backup (dump) functionality of Postgres? Coming from SQL Server (and it seems to me that there’s not a lot of people who have experience with both) - I was really taken by surprise how badly performant Postgres dumps are in terms of both backup and restore speed, as well as backup size of similarly sized databases.

How (if at all) is this related to the ZHEAP development? Sounds like this targets more or less the same problems

Is this a fork or something intended to be upstreamed?

For those who understand russian - there&#x27;s a great overview of this project on RuPostgres channel <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1GgyEqLNXiM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1GgyEqLNXiM</a>

wow.... this is amazing!<p>I dindn&#x27;t get this:<p>`OrioleDB implements default 64-bit transaction identifiers, thus eliminating the well-known and painful wraparound problem`<p>I thought that PG&#x27;s 32-bit transaction identifier and wraparound issue was due to the current MVCC implementation that keeps old versions of rows in page tables, so there is the need to vacuum to clean up the dead rows. So my assumption was that using another approach for MVCC, like the UNDO log, this problem wouldn&#x27;t exist (since page tables would only have the latest version).<p>What am I missing here?

Insanely impressive. If this was available as an extension, I could see us using it in production asap.

Is it just me or is the database scene the new JavaScript scene, new database every week etc.

This looks insanely impressive. Will have to dive in and give this a spin.

&gt; OrioleDB ... solving some PostgreSQL wicked problems<p>Why was Postgres forked?<p>I don&#x27;t want this to come across as negative towards Postgres (or discouraging toward Alexander) but given that these fixes aren&#x27;t upstream in Postgres - developed by a known&#x2F;respected contributor, is this indicative to some type of politics &#x2F; infighting happening within the Postgres community on the architectural direction of their (amazing) database?<p>I see some comments in this thread touch a little on this topic but why does this need to wait 2-3 release cycles before it&#x27;s upstreamed to Postgres? That&#x27;s going to be roughly 4 years from now.

Fascinating and outstanding work. I&#x27;m looking forward to see how well it integrates with Hasura!

How can I contact you to get involved?! This is amazing.

Awesome concept!<p>Any concerns about the name being very similar to OracleDB? At least when I first saw the name I internally within my head read it as that (so could maybe just be me!).