| As I don't want to repeat myself, with emphasis added: > No Silver Bullet, No Free Lunch, and all that. If your problem domain really warrants something outside of relational storage, you're gonna pay that complexity cost one way or another. You can't escape it by shoehorning everything in Postgres, fantastic as a DB as it is. So as not to bloat the system, you will end up bloating your Postgres installation instead. Also, Unix principle/KISS: do one thing and only one thing well. Of course this comes back down to your definition of "one thing". "_Any_ Data Storage" seems to be your one thing but not for me. "Relational Data Storage" is a well-scoped one thing for me. I'm not saying don't take advantage of the plugin system. But we must exercise good sense so as not to abuse it when we avail of its advantages. TFA's suggestion of "only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative" does not sound like good sense. It sounds like a personal and an organizational burnout waiting to happen. Wait until PG is at its limit does not sound like technical debt to you? > If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on. Thus you have conceived the conundrum of The Database of Theseus: after how many plugins is your Postgres cluster no longer a mere Postgres cluster to the point where it is unreasonable for a seasoned/certified Postgres DBA to have a good grasp of the system in a reasonable time span? This is almost textbook https://en.wikipedia.org/wiki/Inner-platform_effect in that this is the second paragraph of the "Examples" section. I acknowledge that Postgres' plugin system mitigates this somewhat but I just can't be convinced that all those plugins will play well with each other for all eternity and especially under stress (unless you make a PG instance for each sub-system, in which case, refer to my original comment). For the record - I've used PG for caching with UNLOGGED. Still had Redis for a message queue and other caching.
- I've used PostGIS because it made sense to be able to make geo query when latlon is already a (small) part of your schema.
- I've used JSONB but only because the alternative is Mongo. I still had an Elasticsearch cluster indexing all that data for search. |