News for hackers. Stuff that matters.
Re:Why Uber Engineering Switched from Postgres to MySQL by smoodles on Tuesday July 26, 2016 @02:18PM (#12167668)
Operating Cassandra at the scale that Uber is going to require is going to be painful and as operationally draining as MySQL if not more.

There are really not a large number of options here anymore with the departure of FoundationDB from the market. CockroachDB might be an option in a few years, though I'm still confused why they are moving towards a SQL-ish vs key-value interface...

Re:Why Uber Engineering Switched from Postgres to MySQL by nickpsecurity on Tuesday July 26, 2016 @02:52PM (#12167933)
"departure of FoundationDB from the market"

Pissed me off so much. Only thing close to Google's F0 RDBMS on the market, at a reasonable rate, and the beginning of a good offer to enterprises. Then, "poof!" It's a good example of why I tell companies to not put anything critical into something from a startup. If they do, better have a synchronized, backup option tested and ready to go.

"why they are moving towards a SQL-ish vs key-value interface..."

That's easy: most databases and buyers use SQL. Key-value is preferred by startups & non-critical, side projects in big companies you see here a lot but aren't representative of most of the market. Need first-rate, SQL support. I think EnterpriseDB shows that it's also a good idea to clone a market leader's features onto alternative database.

Re:Why Uber Engineering Switched from Postgres to MySQL by ngrilly on Friday July 29, 2016 @04:43AM (#12185632)
> Only thing close to Google's F0 RDBMS

Did you mean F1 (instead of F0)?

Re:Why Uber Engineering Switched from Postgres to MySQL by nickpsecurity on Friday July 29, 2016 @08:24AM (#12186340)
Yeah, yeah. I keep getting the 0 and 1 mixed up. Thank you.
Re:Why Uber Engineering Switched from Postgres to MySQL by ddorian43 on Tuesday July 26, 2016 @03:40PM (#12168241)
What dbs would you suggest in their scale ? that are easier operationally than cassandra ?