|
|
|
|
|
|
by roenxi
2401 days ago
|
|
|
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. |
|
|
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
[1]: https://timescale.com
[2]: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...