My little business uses PG. Had a unique need for PK IDs. It was pretty easy to make a little extension in C to generate them for us, and linking in PG was super easy (but the .so has to be on replica before loading) and we only used the TEXT type cause I didn't want to figure out making a new 128bit data-type. But can't do this in RDS.
Postgres has all sorts of great stories for customisation. It does custom aggregates better than MySQL or SQL Server, for example, because you can just write them in SQL with not hassle.
Storing data is the most universal task in the software ecosystem. Data storage will be confronted as a problem by everyone even tangentially related to software - the Truly Inspired Software Engineer, the Almost Incompetent Software Engineer, the Developer, the Manager, the Lawyers. The Customers will care, sooner or later it becomes their problem. The Subcontractors care. Even the Government cares about data storage.
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.
> It is a not a problem where 'unique' or 'customised' are competitive advantages. 'Boring', 'available', 'reliable' and 'well understood' are competitive advantages.
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.
I don't think I can get any extensions loaded if I use RDS. They've basically handicapped what I'm reading is one of the most useful features of postgres
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.
If RDS won't support the extension, it might as well not exist. Well, almost might as well. I'm lucky I don't need sfcgal but if I did I might give up on RDS.
I ran into this quite frustrating limitation recently twice in one day, for two different tasks. The MongoDB foreign data wrapper for a legacy data access task, and the rational numerical library for storing accurate fractions for a project dealing with financial data containing multiplicative rates and times where the cumulative floating point errors were throwing off final calculations.
