Did you consider Postgres with hstore, or Redis? Would be interesting to hear what the pros and cons of these solutions were for you.

There’s at least as much difference between Neo4j and Redis as there is between Redis and MySql.

You have to look at your problem space before deciding on a database technology. It’s pretty obvious from Sauce Labs statements on how they use MySql that they don’t need a relational db at all. They needed a reliable document store that scales without being I/O bound. They won’t run into any of the issues that cause most people to look at NoSql over relational – i.e. range based, ad-hoc or aggregate queries over very large datasets. These are the some of the primary driving forces behind map/reduce and NoSql. They could probably get by with a really large SAN, fronted by Redis to hold indexes. Or if they can do hosted – go directly to DynamoDb.

Seems to me the issue in Sauce Labs case was mischaracterization of the problem to be solved and selecting a solution without defining the requirements.

I build real time data collection systems that collect a LOT of data and I find the best way to come to a decision about data storage is to define the requirements of my application with no storage in the picture at all. Once I do that it becomes obvious what I need to solve the problem.

It has so many powerful features that you just do not get with MySQL, and we have found performance to be an order of magnitude greater once you start doing more complex works.

For me the most telling statement in the rather ill informed Saucelabs writeup is that in MySQL it’s par for the course to have to worry about FORCE INDEX statements. In Postgres you can simply let the planner get on with it’s job and it all just works.

As others have stated SQL isn’t just some cumbersome mistake that’s there to get in your way. It provides a rich and powerful environment in which to work with your data. With powerful features such as windowing functions and WITH queries (which even let you wrap INSERTs, DELETEs, UPDATEs and SELECTs into single compound queries requiring a single round trip to the database eliminating some race conditions) you can access, query and manipulate your data in ways that the NoSQL crowd can only dream of.

CHECK constraints and triggers can be used to ensure your data is always integral and internally consistent. This isn’t just a nice to have it is vitally important as you scale and end up with multiple developers working on the same system and / or have multiple programs inserting and manipulating data. Knowing that bugs cannot lead to garbage data (at least structurally) gives amazing peace of mind and leads to fewer application level checks, also reducing the error handling that is required.

Finally please do not listen to anyone who says that an application should store its own data and be directly responsible for storage performance. The application should make best use of the established tools that are available rather than reinvent the wheel. Writing a data storage engine that is more reliable, efficient, powerful or flexible than any of the SQL databases out there (or even the NoSQL databases) is a seriously non-trivial problem and is almost guaranteed to lead to data loss at one time or another as well as sucking up vital resources and massively delaying your projects time to market. Scalability is almost always a nice problem to have, worry about building the best application you can first and resort to drastic action to scale your application only once you have exhausted all your other options.

“No schemas. This was wonderful. What are schemas even for? They just make things hard to change for no reason.” Right. I’m sure that all the work that Edgar F. Codd did to invent relational database schemas was just to make them hard to change, to piss off the Sauce Labs crew some 40 years later. You noobs obviously know nothing about relational calculus. http://en.wikipedia.org/wiki/Codd%27s_theorem

“Non-relational. Relational databases grew up solving problems where data integrity was paramount and availability was not a big concern. They have a lot of features that just don’t make sense as part of the database layer in the context of modern web apps.” More of the same ignorance. Yeah, modern web apps don’t need stuff like ACID data persistence. Who cares if we lose the data, or if the data we get back is wrong but without any indication of error?

The fact that little MySQL makes your data way more “available” than CouchDB could seems to make that statement even more ludicrous.

“No SQL. It’s 2012, and most queries are run from code rather than by a human sitting at a console. Why are we still querying our databases by constructing strings of code in a language most closely related to freaking COBOL, which after being constructed have to be parsed for every single query?” Guess you clueless beginners have not heard of prepared statements — parsed once. And you conflate SQL with relational database — since there are relational databases that do not use standard SQL. Although why you’d not use one just other than your irrational fear of “Teh SQL!” it’s hard to imagine. Better start coding in binary machine language, because all that text you write as code is “strings of code in a language most closely related to freaking [some older language]“.

N00bs. Punks. Come back and make this argument in 20 years.

Ultimately, the best applications in the world today, in terms of performance and scalability, are applications that take direct responsibility for their own data storage rather than farm it off to a database product. Meaning that the application is aware of scaling and sharding and its developers are forced to deal with those issues every time they interact with the storage engine.

If you take such an approach, it hardly matters whether the ultimate storage is done with MySQL or Couch or Mongo or something else. True, SQL is philosophically designed to abstract storage details from the developer, but you can ignore that abstraction by eschewing things like foreign keys and joins as the developers have done here.

Oracle may well outperform MySQL on a per-machine basis. As a developer working on a scalable solution, I shouldn’t depend on that to make or break my product. If I design something truly robust, and truly scalable, then I ought to be able to do what I need simply by increasing the number of nodes without regard to the performance of any individual machine. That is the mark of a successful high-scalability solution.

Frank

“We already know it” does not make it the right choice for the job. Good engineers learn the tools needed to do the job right, not just how to hack together familiar pieces that they hope will work.

In the free RDBMS space Postgres performs better, scales easier, and behaves far more consistently than mysql can ever hope. Percona and Xtradb are nice, but inadequate compensation for all the other hack idiocy in mysql. It is truly the PHP of databases (and its sponsor keeps it that way). That more people don’t see this and switch to Postgres is tragic.

Outside the RDBMS space there are lots of great projects not even mentioned here, like Cassandra (on one end of the scale) and Redis (solving a different problem on the other end). Our architecture uses all three in various places (Cassandra, Postgres, and Redis).

I don’t know enough about your needs to evaluate your persistence architecture, but mysql … well, best of luck. You’re going to need it (remember this in a few years).