4 ms·
I like the idea of "defining the edges of suitability." Just because you can use it, does not mean you should. I lean towards fewer tools. Postgres is an aweso
by koliber 3y ago
I like the idea of "defining the edges of suitability." Just because you can use it, does not mean you should.
I lean towards fewer tools. Postgres is an awesome swiss army knife. In some cases, using it as a key-value store, a cache, or a messaging queue are fine. In other cases, they're not.
Examine how suitable this particular tool is for your particular use case and your particular requirements.
Maybe you have zero DevOps skills, a background in DB administration, and your cache backs an external API. Perhaps using postgres is the right solution.
Maybe you know enough about databases to be dangerous, but feel comfortable managing virtual clouds environments. Perhaps DynamoDB or a Redis instance is the way to go.
There is no one answer. However, often there is a good default answer.
P.S. The default answer changes over time. There's always the flavor-of-the-year. The technology landscape is also constantly shifting. My heuristic is to use lean towards the default answer that has been around the longest.
- osigurdson 3y agoI can say, using pg as a time series database works completely fine for < 1B rows. If you have significantly more than that, it is a good idea to start thinking about alternatives.