> [we were] storing a large time-series table
saved you a click
saved you a click
Postgres is very very good. The vast majority of use cases work with it with very minor effort. People would, in general, be better off investing in thoroughly understanding a general tool like postgres (or similar dbs, just pick one to learn, but there are reasons why you would pick postgres over, say, oracle).
There are still reasons to use more specialized DBs. But the push for postgres is because very often the people reaching for those specialized DBs do so in error.
20M rows is practically an in-memory dataset, for example.
You can scale up a lot with a general purpose RDBMS like postgres on a single server, and a read replica today.
It's not perfect, or even ideal for many workloads or even all environments... But it probably can be good enough for most application needs.
It's knowing when it isn't, why it isn't, and what to use instead that counts in those instances. But I hold no blame for starting with what is probably one of the better known and understood solutions to start with.
A fully relational time-series database like Timescale (a plugin db built on Postgres) gives you full SQL analytics, including aggregations and full relational joins with other data, which is where a lot of the value-add usually is. This also opens up the field to building multivariate machine learning models.
The amount of work you need to do to make it not worth it is quite high assuming it can be done which they seem to have accomplished pretty easily by DIYing their own provisioned iops rds (not sure why they didn't try that).