thinkx

monumental? OrioleDB works anywhere where you are running your own self-managed Postgres instance.. be it on bare-metal, or VMs, or EC2.

this is NOT a new database

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.

HTH

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

Coming to Postgres, UNDO logs and no vacuum

https://github.com/orioledb/

take a peek at https://github.com/orioledb/orioledb if the Uber blog is your frame of reference

we’d love to test this scenario with the new OrioleDB storage engine for Postgres.

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

Find out who has invested in EDB, the leading Postgres vendor in the market. Postgres is a foundation, so there is no central entity to invest in.

Postgres has a core design philosophy of being “extensible”. This should be embraced..

> 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?

Bruce Momjian wrote a few blogs about code quality.. the phrase “brutal replacement of old code” comes to mind

> though there are trade offs.

Please elaborate on this, it would be instructive

that’s a throwaway opinion, worth the time you spent writing it

what replaced Schemaless?

It is unfortunate that Kdb+ likes to tout benchmarks against Influx etc, but their license prevents anyone else from doing the same.

Long time gestating.. awesome to see a full-blown open-source product!