I mean, you can go a loooong way on Postgres. Things that probably are going to start causing issues: - the story of replication - ultra-high volume write con

I mean, you can go a loooong way on Postgres. Things that probably are going to start causing issues: - the story of replication - ultra-high volume write contention - high volume timeseries data streams For #3 there, I was consulting on a project a few years ago where there was about 1 gigabyte of timeseries data in Postgres/RDS. Some ad hoc queries were really running into slowness - COTS RDS isn't great at speed. I want to say 1 billion rows, but that seems a off. Anyway, we were talking data sharding, etc. Didn't go anywhere, because the project was canceled, etc. But we could have done a nice job if we wanted to. Point being, there are design limits on postgres, particularly regarding distributed systems. Which is fine. I just have this allergy to designing for scale on Very Small Project. Also worth noting that the anti-monolith dogma plays out here, a few well built monoliths probably are better for a SQL database than "one bajillion microservices".