How come many startups used MySQL or PostgreSQL rather than MongoDB when they began?

Many of them seem to migrate to MongoDB later - why's that? To be clear I have typically seen "sub-systems" moved to MongoDB. Generally to handle the things where SQL is not great. There are also some people who have moved off MongoDB. Or are very unhappy with it. http://blog.schmichael.com/2011/11/05/failing-with-mongodb/ http://pastebin.com/raw.php?i=FD3xe6Jt As much as I like MongoDB it is not a Panacea. Does it need a lot more effort in working with MongoDB? MongoDB definitely makes some problems easier. It's easier to write real-time counters, it's easier to make basic schema changes (like adding a column). It's also a clean coding fit for solving certain classes of problem. However, there is also extra effort required from the operations and training side. The SQL databases are all well-documented and well-supported. Your operations team probably knows very little about MongoDB and it is a very different beast. It's not really a free lunch, it's a series of trade-offs. Some things are better suited for MongoDB and others for SQL. Personally, I suggest & use a combination of both. My current start-up uses MongoDB for some types of data and SQL for others.

Coming from a rails background, I'd say that most startups I've seen select MySQL or Postgres first b/c it's the best documented way to use Rails. Swap out the sqlite adapter for postgres or mysql and you're done. In a lot of ways I support that because the quickest route to market is usually the best, I think - but I do think many startups would benefit from starting off on NoSQL first.  Especially in cases where pivoting is likely and features will need to be removed/added as quickly as possible.  That's really an area where NoSQL shines. Full disclosure: I'm a cofounder of Stretchr, a NoSQL solution that is at least partially attempting to reach that market.

MongoDB (while a very capable database) is not a solution to every data storage problem nor is it well suited for relational data as MySQL and PostgreSQL. Data storage is a case-by-case problem and needs to be evaluated beyond just using the latest and greatest database. For relational data MySQL (and the other SQL varieties) are the best of breed and have decades of documentation, community support and usage and will be hard to beat. Most data ends up being relational and the convenience of joins, ad-hoc queries and powerful indexing, security of schemas and data types and the ACID guarantees are almost always worth more than whatever flexibility you can get from a document database. MongoDB is easy to develop for but there are lots of downsides like data integrity, write-locks, lack of relations, no type checks, and overly complicated and fragile scale-out architecture. It can be great for some specific uses but as always there are trade-offs.

Like said, it is not really a free lunch. Some things are better suited for Mongo and others for SQL.But when you ask why do startups choose MySQL when they do, this is mostly why we do. Setup : Bootstrapping is a lot simpler and there is enough and more documentation to help us out. Proven : http://www.mysql.com/customers/ will tell you why. Effort : Startups, as it is have a lot of confusion w.r.t the product direction, in trying to decide what will sell, prioritizing and decision making. The last thing anyone of us would want to do is to experiment with technology stack. However cool and awesome your technology is, you need to get out your product faster and most of us have gotten used to using MySQL way too much (fortunately or otherwise). Product Understanding : A lot actually depends on how you understand your product. Brilliant ideas and amazing thoughts come only after you are done with your first prototype. MySQL is a safe bet in such a scenario because every product will eventually have other data stores (Read document, key/value) and it is lot more easier to come up with schemas for the latter because you have already done your dirty work with MySQL. The worst of MySQL schemas still give you considerable performance as opposed to the worst of other fancy things (As an example, try creating a document in mongo that is not self contained but requires multiple joins (because that's how our data models look like when we are prototyping) - In this case with the latter, you can easily travel to North Pole and come back by the time you have your queries executed. (This might be a bit of an exaggeration) Resources : People who understand non-classical things don't come cheap. You'll do yourself a lot of good by using MySQL as your primary database if your team doesn't have champions.

Its really easy to boostrap off of mysql or postgresql for that matter. There are loads of code samples that are based on those two databases. So its much easier, and the startup can focus on delivering its product, rather than investing time on the technology. What happens later is, since they have mostly delivered the product, they now look for optimizations. This is where experimentation begins, and they later find out that MongoDB is a good solution for many of their schema problems, or is better in some way than their existing sql platform. Though personally I know, most of the problems of MongoDb can be solved at the application level.

I did the same thing in my startup, just because I knew MySQL and it was easy for me to start with, but as I completed the design of my application schema, I realized there must be a better solution, because this is going to be a nightmare working with flat tables and too many of them. then I had a "Brilliant idea" I'll write some kind of a JSON data solution on top of MySQL, I actually started doing that, but then I thought, I am probably not the first guy around to go through this process, let's check this new thing - the internet, and see what's happening in this field, found MongoDB, and... fell in love...