It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres.

Why not combine Postgres for OLTP workloads alongside another database for fast analytics/time series, optimised to deal with high throughput ingestion and low latency queries?

NB: I am one of the co-founder of an open-source time series database (questdb)

TimescaleDB

Any thoughts on Timescale?

Unfortunately, you cannot install timescale on an rds, or I believe , other managed Postgres services : https://stackoverflow.com/a/67712962.

https://www.timescale.com/ - they offer this as part of Timescale Cloud

Clustering it is still a pain, certainly if you want a proper autoscaling master-master setup. (Which may not be necessary for performance, but is still what you need for availability/resilience).

And it's still too easy to shoot yourself in the foot, by deadlocking, or using up all the server's resources with a query that looks very similar to one that was fine.

However, you didn't return to postgres:6.0 (first formal release in 1997 [1]), you returned to postgres:latest, which included the lessons learned from lots of other databases, thinking here of postgres:9.2 (in 2012) adding native JSON support making Postgres basically NoSQL with extra steps. Contrary to popular wit, reinventing the wheel is always beneficial, if it will not bring something new to the world, it will at least make you understand and appreciate wheels better.

[1] https://en.wikipedia.org/wiki/PostgreSQL#Release_history

Seems like there are a couple of people with this mindset at every company. “Let’s write X”, “are you crazy, no one writes X! We can use Y!”, “But Y lacks Z”, “No! The thing you want Y to do is bad! You should not want Z! Do W instead - it is the correct way”

Stop larping as graybeards, and try to actually do something instead of endlessly bike shedding your cargo cult.

They don't bet against Postgres

Betting against Postgres all the time, since the .com age I have mostly used Oracle and SQL Server, and Postgrest only in a single projec that was alive during 4 years.

There was also Informix, SYBASE and DB2, but those hardly matter nowadays.

Why doesn't DB2 matter?

It still does, however it is mostly for IBM customers on Aix, IBM i and z/OS, not was widespread as it once was.

> What can’t it do.

Async I/O.

>>Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres.

Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do).

I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch.

I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.

> What can’t it do.

Fail over without downtime or operator intervention.