3 ms·

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

dangoodmanUT 2y ago
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
- akulkarni 2y ago
  (Timescale co-founder) We actually have 100s of customers who use Timescale for their production time-series _and_ OLTP workloads :-)
sophacles 2y ago
Which corners, and what dangers?
- VeejayRampay 2y ago
  those corners do not exist, but people love yo create artificial needs to justify unneeded complexity
monero-xmr 2y ago
I don’t know about timescale specifically but using Postgres for everything is the safest thing you can possibly do as a startup.
smt88 2y ago
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.
- vrosas 2y ago
  > 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.
  - smt88 2y ago
    Assuming you're tolerant of downtime, why would it be a huge undertaking? You could write the code to do it in 10 minutes.
whateveracct 2y ago
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.
- schainks 2y ago
  Can you say more about this? Seems like an organizational / communication problem than a technical one.
  - dboreham 2y ago
    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.
- vrosas 2y ago
  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.
- simonw 2y ago
  That's a great problem to hold off on tackling until you have hundreds of engineers.
from-nibly 2y ago
Not any more dangerous than any other technical choice.
ZitchDog 2y ago
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

akulkarni 2y ago
(Timescale co-founder) We actually have 100s of customers who use Timescale for their production time-series _and_ OLTP workloads :-)

sophacles 2y ago

Which corners, and what dangers?

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

monero-xmr 2y ago

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

smt88 2y ago

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.

vrosas 2y ago
> 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.
- smt88 2y ago
  Assuming you're tolerant of downtime, why would it be a huge undertaking? You could write the code to do it in 10 minutes.

whateveracct 2y ago

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.

schainks 2y ago
Can you say more about this? Seems like an organizational / communication problem than a technical one.
- dboreham 2y ago
  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.
vrosas 2y ago
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.
simonw 2y ago
That's a great problem to hold off on tackling until you have hundreds of engineers.

from-nibly 2y ago

Not any more dangerous than any other technical choice.

ZitchDog 2y ago

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".