OrioleDB is based on earlier work done in the core Postgres to introduce a storage extension framework called Table Access Methods.
This phase adds significant enhancements to make the OrioleDB extension feasible and aggressively performant.. and the delta code to be committed upstream is less than 2K LOC.
Comparing this project to earlier forks that got stuck at 7.x and 8.x would be a huge disservice to the maturity and extensibility of the Postgres project.
On your latter point, OrioleDB does not “replace” the built-in storage engine (which works quite well for many many use-cases), it “augments” the core capabilities with an additional storage engine optimised for many use-cases where the legacy engine struggles.
stay tuned, there is a concerted effort to bring this area up to standards too.. more details will be discussed at the upcoming PGCon Ottawa and you will blogs on this subject in the latter half of the year
only the additional “hooks” for Table Access Methods need to get up streamed into the core Postgres. OrioleDB is a separate storage engine and not designed to replace the current engine, and be used as an adjunct storage option
important distinction - this uses the Postgres Table Access Method to add an additional storage engine to the Postgres platform.. this is NOT a replacement for the current storage engine and can co-exist and be used on a per-table basis
> MySQL is a perfect match for most SaaS applications that deal with compliance. Postgres is simply not.
Please elaborate on this “simply not”.. you are making a categorical statement.. does there exist a DISA-certified STIG for MySQL, for DoD and military applications?
this is NOT a new database