News for hackers. Stuff that matters.
Re:The Uber Engineering Tech Stack, Part I: The Foundation by rantanplan on Sunday July 24, 2016 @10:57AM (#12153467)
The above is good as a rule of thumb indeed.

Another one that I'd add is: - "Are the records in each table in the hundred of millions? Then most probably you'll do fine with an RDBMS".

If you go above that, or you have operations that will extrapolate that number in the billions then you can offload them into whatever non-RDBMS storage you want and do your thing. But that's the thing with RDBMS, you can always move(or offload part of) your data to a non-RDBMS solution afterwards.

But doing the inverse? I wouldn't want to be in that person's shoes ;)

Re:The Uber Engineering Tech Stack, Part I: The Foundation by brianwawok on Sunday July 24, 2016 @11:00AM (#12153473)
Does row count matter that much compared to data size? I.e. if I have a billion rows but they are 2 32-bit ints, that isn't a lot of data (2 GB + index). I guess the index starts to get pretty big.. but I always just think of raw data size vs # of rows.
Re:The Uber Engineering Tech Stack, Part I: The Foundation by rantanplan on Sunday July 24, 2016 @11:13AM (#12153499)
Remember, it's just a rule of thumb. Now... tables with 2 32-bit ints as columns are not exactly typical RDBMS data.

Also, data in RDBMS are... well relational :) Meaning, the rows of just one table are not that important. The data are going to be queried and combined with data from other tables. And I know that typical relational data that consist of hundreds of millions of entries in each table is something that most DBs can handle.

Again, rule of thumb :D

Re:The Uber Engineering Tech Stack, Part I: The Foundation by brianwawok on Sunday July 24, 2016 @04:44PM (#12154805)
Fair enough!