It is a not a problem where 'unique' or 'customised' are competitive advantages. 'Boring', 'available', 'reliable' and 'well understood' are competitive advantages. Relational databases are a great way to store small quantities of arbitrary data and PostgreSQL is a textbook relational database.
This analysis overlooks the importance of "hype" and "convenience" in the marketplace -- case in point, MongoDB. To this day people are realizing what a mistake it was to abandon constraints and transactions given to them by their "textbook relational databases".
> Relational databases are a great way to store small quantities of arbitrary data and PostgreSQL is a textbook relational database.
Just want to make sure no one is mislead by this, Postgres scales to the amount of data needed by I'd argue 90%+ of the companies -- I'd bet my money on a single appropriately configured small-to-midsize Postgres instance being enough to handle your business needs for the next 10 years (if your company lasts that long) and beyond.
Also, Postgres's flexibility is indeed a huge competitive advantage. It can handle both full text search[0] (which I argue is usually good enough) and timeseries[1] data (better than InfluxDB can, in some cases[2]), made possible by it's extensibility. This is a competitive advantage for small to midsize companies that don't want to dedicate one person to mastery of Elasticsearch (which is often necessary), along with deploying & managing more infrastructure.
[0]: https://www.postgresql.org/docs/current/textsearch.html
[2]: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...
Except for using the OS Page cache and not managing the buffer pool (very much) itself. It's the only database that does it that way.
But compared to the wide and wonderful world of available options, this list is extremely short, and missing basically all of the Foreign Data Wrappers.
You can't really just let people load any old .so that could happily fopen() anything it wants on the host etc. They need to vet them.
