Hacker News Reader

Comment by dangoodmanUT | Hacker News Reader

On the other hand, this is backing companies into corners that are dangerously hard to get out of.

Postgres is the only RDBMS that is not backing companies into corners because so many products are forks of it or "speak" Postgres. You can completely swap out your database without changing any of your code. There is no other database that lets you shop around (or upgrade to a more specialized product) like that.

> You can completely swap out your database without changing any of your code

Uhhhh in theory... maybe... not really. Switching PG out from under our relatively toy-ish SaaS product would be a huge undertaking.

Assuming you're tolerant of downtime, why would it be a huge undertaking? You could write the code to do it in 10 minutes.

I would much rather inherit and optimize someone's postgres DB with specific scaling challenges than a prematurely optimized multi-database solution built for "web scale".

And on the third hand, Timescale is not advised to be your production OLTP if you're using Timescale cloud, so it's a strange double-standard that they are communicating here since they cluster totally differently than normal OLTP postgres workloads? Or maybe I skimmed it to fast and haven't used Timescale in a while

(Timescale co-founder)

We actually have 100s of customers who use Timescale for their production time-series _and_ OLTP workloads :-)

100s of engineers all coding against the same Postgres database becomes a pain. Lack of decentralization leads to silly outages due to people sharing resources they really shouldn't.

In my experience it's really hard to prevent issues like this. RDBMS's kind of push you to keeping everything in the same database to take advantage of foreign keys and other features when in reality different data types will need their own source of record. I consider myself more experienced than most and I still fell into this trap in recent memory, failing to expect the scaling requirements for one of my tables until it was too late.

Can you say more about this? Seems like an organizational / communication problem than a technical one.

Not the parent but I've seen this scenario a few times. Essentially what you get is random groups of devs (often you never even knew they existed or were messing with your DB) who mount a DoS attack (not their intention but that's the result). Long lived transactions, unindexed queries, unexpected deadlocks, etc etc. Worst thing is their reaction is that your database sucks. So no amount of education will fix the problem. They think you're the problem. So you end up with a defensive architecture where the blast radius for any single act of stupidity is limited.

That's a great problem to hold off on tackling until you have hundreds of engineers.

I don’t know about timescale specifically but using Postgres for everything is the safest thing you can possibly do as a startup.

Which corners, and what dangers?

those corners do not exist, but people love yo create artificial needs to justify unneeded complexity

Not any more dangerous than any other technical choice.

Reply on news.ycombinator.com