The long tail of startups will rarely need something other than a relational database because they won't get to a scale anywhere near Reddit's. It's not that others don't "feel" the same way; there's a reason all those technologies exist. If you want to know, go work for Google, Twitter, Facebook, LinkedIn, etc.
I would argue the exact opposite. The average startup is likely using MySQL as a glorified key-value store already anyway, and they're likely using it in lieu of a more appropriate datastore because people tell them they don't need a NoSQL database until they get to Google-size.
The lesson is: match your database to your use-case, not the other way around. Need advanced querying/reporting options? Get a warm, fuzzy feeling from a SQL prompt? Use MySQL. Want a plain jane key-value store? Use Voldemort/Kyoto Cabinet. Want flexible schemas? Use MongoDB. Want a Key-value store with secondary indexes and lots of scaling capabilities? Use Cassandra/HBase. Want a powerful datastore that's supported by a BigCo? Use DynamoDB or Cloud Datastore.
That's not the exact opposite. Because most people are familiar with SQL databases, that's usually what they use. That's the case with the grandparent post. "Use what you know, and works for your case" is better for a startup than learning a trendy technology because you believe it might be better for your use case.
Three years ago at IndexTank we were looking for a SimpleDB replacement because it just didn't work as advertised. We explored a bunch of options, and we paid a significant cost to find out that deploying Cassandra would not be worth it for us. If you have never used Cassandra and choose it because you "want a Key-value store with secondary indexes and lots of scaling capabilities" then you're in for a world of hurt.
For some reason, you seem to be reducing my argument to "Use the shiniest technology possible!". Please don't strawman me.
If MySQL works for your use-case, and it's the option you're the most familiar with, use it. You'd be doing yourself a disservice by not at least evaluating other options though.
And Cassandra is a key-value store with secondary indexes and lots of scaling capabilities (such as multi-datacenter deployments, multi-master replication deployment)[1], and some companies who aren't Google or Facebook do need these things. It sounds to me like IndexTank wasn't one of those companies.
I reiterate my point: choose what's best for your company, and don't settle at MySQL just because it's "good enough".
[1] I'd also add that it's particularly suited for large, insert-heavy datasets.
There is literally zero appropriate use cases for mysql. If you need a relational database, use one. If you need a network hash table, use one. Don't use mysql at all.
I agree. There is no proof that MySQL cannot do the job when configured correctly. Furthermore, another issue is with coding. Sometimes unnecessary nested "if" statements can cause huge problems no matter what type of database you use.
>MySQL is a high performing, highly scalable, ACID compliant relational database, when configured correctly.
You forgot the "with tons of brokenness, misfeatures, mistakes, problems and otherwise NOTABUG bugs that will never be fixed and cause immense amounts of pain". Literally every other RDBMS is a better option, thus there is no reason to use mysql.
Simply repeating anti-MySQL rhetoric is not going to convince anybody that it has actual problems, just that you've had bad experiences in the past that have biased you strongly against it.
It's particularly not going to convince people when it's so widely used (from Wordpress installations to Facebook), and perhaps more importantly when it's offered as part of the two largest VPS providers.
On topic, I'd be happy to offer some advice on how to set up MySQL in a way that limits (or eliminates) the concerns proffered by most "MySQL is not Production Ready" comments... the two most oft cited problems being sorted by the following two my.cnf settings:
You can avoid buffer overflows in C by using a library that's got safe strings.
Does that make C safe? Nope.
The Windows NT architecture has an enormously rich security mechanism that can allow arbitrarily granular security statements to be made about almost everything. But the default policy until Windows 7 was "pretend you're Windows 95".
Did that make Windows more secure than Unix? Nope.
I don't like rhetoric either. I think it is good to consider the facts, and for me generally the situation/environment/problem as much as possible.
I like to consider the problem, before I recommend a solution generally ( I don't mean to accuse you of pushing a solution, I think you are offering help which is always appreciated ), but I think a lot of people are used to having had the choice already made ( and indeed, in some circumstances it is!).
One thing I always try to remember about mysql, as it is is less than intuitive to me, at least that there is no way I am aware of to alter or restrict this behavior directly, is that in mysql the client is allowed to alter the sql-mode ( I do think I have used proxies to filter out this behavior as a sort of guardian, but that was not an ideal fix by any means ), generally if you don't have control of your clients ( or also hopefully some good layers in front ) in the RDBMS world you are already sunk, but this has been more as a guard against accidental breakage for instance.
This can make it unsuitable for certain situations ( where you may not have control of the client ).
One thing that I think is both a strength, and a weakness ( again depending upon the situation ) is that mysql is very flexible and can be deployed in so many different configurations.
Generally I think it is best for people to carefully consider their situation and needs ( and be prepared to change when the situation does!).
I really enjoy working with Postgresql as well, and have long respected the code produced by that project.
In summary, I'd say there are many great databases ( both relational and otherwise!) which can be a real asset to solving problems. The best thing I think is to learn directly and continually :)
>On topic, I'd be happy to offer some advice on how to set up MySQL in a way that limits (or eliminates) the concerns proffered by most "MySQL is not Production Ready" comments
There are no settings for "make triggers actually work", or "remove arbitrary limitations like being unable to update a table referenced in a subquery", or "make views with aggregates perform well enough to be used", or to add expression indexes or check constraints or window functions or let you set defaults to functions or to have a transactional DDL or to make rollbacks not corrupt the database or to allow prepare/execute in procedures or to allow recursion in procedures or to allow triggers to modify the table they were fired against. That's the point, mysql is full of crippling limitations. There are non-broken databases available that are superior in every single way. Thus there is no reason to use mysql. I know quite a lot more about mysql than you seem to think I do, and there is a reason that the only thing I do with mysql is conversions from mysql to an appropriate database that actually works.
Reason to use MySQL: It's easy to find people comfortable with it that won't accidentally shoot off a toe doing simple things.
The "Don't use MySQL" argument smells like the "don't use bcrypt" argument to me. You're letting the perfect be the enemy of the good, for 95% of the usecases where you're doing something dumb like using MongoDB or homebrewing something, MySQL is a better choice--even if it isn't often the best choice.
I've never seen a single mysql database where there was no toe shooting happening. People just don't seem to miss their toes. In 100% of the cases where you used mysql, postgresql was a better option in every way. It isn't letting perfect be the enemy of good, it is saying "don't use bad software when there's good software available".
As a differing example of scaling - Facebook works very well using MySQL at a very large scale; implying that you don't need to move to key/value stores to scale.
Both technologies have their place and reasons to exist, but it's not solely for the ability to scale.
Do you have a citation for this? The closest I could find is a mention in a gigaom article[1] that mentions that they have some data better suited for a document store tool, but saying "there likely are unstructured or semistructured data currently in MySQL that are better suited for HBase" doesn't imply that the majority of their data is key/value based.
If you'd like another example at slightly less than Facebook size - RightNow (recently acquired by Oracle). They manage customer service for many (1,000+) different clients at huge scale: more than 300 MySQL databases spread throughout the world. If a website has a knowledge base, there's a good chance it's being managed on the backend by RightNow.
