I would tend to say that MongoDB is the new MySQL in a different way - it's the default not-really-suitable hammer that the current generation of amateur software carpenters are using to turn every problem into a nail. It's not super elegant, but most of the time it works, sort of.
On the bright side, one could say that at least half of the PHP/MySQL tag team has been improved significantly by being replaced with Python/MongoDB, as theological issues aside, Python is a lot less broken than PHP :)
"I would tend to say that MongoDB is the new MySQL in a different way - it's the default not-really-suitable hammer that the current generation of amateur software carpenters are using to turn every problem into a nail. It's not super elegant, but most of the time it works, sort of."
that's an excellent - and much shorter - way of putting it.
For what projects (besides enterprise -> Oracle, embedded -> SQLite and Windows -> SQL server) would you consider MySQL inappropriate? What would you use instead?
I see people angry about not using the "right tool for the job" all the time with regard to web applications. What other tools do you feel aren't used when they should be?
I think that one of the reasons that MongoDB is getting traction is that many people don't use relational databases in a relational way for many projects. Lots of data just isn't as relational as we hope it would be and also people are terrible at modeling data in a relational way.
Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity relative to many databases, so many devs don't care about only having one copy of a piece of data in the DB.
Also, SQL is great as a data retrieval language, but it is awful for inputting data. Yes, it works, but writing data to MongoDB in general has felt more natural than generating SQL to shotgun in data.
You could argue that ORM's solve a lot of the uglyness of inputting data into a DB and I agree with you, but you still have to deal with table migrations and being able to just add a field in your code and not have to go hold the database's hand or write a migration to make it work is incredibly convenient.
In the end, MongoDB solves a lot of convenience issues for programs that don't need relational data or programmers who don't want to use an ORM, create SQL strings, or write migrations to get their database to store their data.
It's not for everybody, but if it fits your needs, it solves some problems much more conveniently than MySQL.
I agree with your first comment: a lot of people suck at creating models that are relational. It's also difficult to use relational data outside of a relational system: when you retrieve it from your RDBMS and get it as, say, a Python dictionary. This is the big problem with using SQL for the web.
However, I disagree with your other statements:
(1) we do not have infinite storage. Most data stores keep everything in RAM, and that is pretty limited.
(2) It's really easy to input data into SQL. There are in fact a bunch of methods to do so (almost all still rely on SQL).
(3) (more of a comment, than disagreement) ORM's don't solve much. They just remove the need for engineering a data access API and trade it for performance and cleanliness of code.
>also people are terrible at modeling data in a relational way.
While true, I don't think this is quite fair. Not all of our clients/employers are huge entities with business processes and data requirements that are stable for decades. Many, if not most of the projects that come across the desk of an IT developer are temporary projects with indefinite scope.
One of my current projects is modelling a rather complex set of intertwined business processes. Part of the problem is just getting the client to explain their existing processes completely. Another part of the problem is that the processes are always changing. As soon as I think I finally have all the data models figured out, there's one more tweak. I am not great at data modelling or SQL, but tweaking a dozen 50 line joins on a daily basis is not happy fun time for anyone. At some point the specced data model, the model as implemented, and the conceptual model that's in my head get out of sync in some mysterious way, the plot is lost and it all turns to shit. On top of this I'm also trying to manage an object model that sorta maybe corresponds to the data model. In cases where the spec changes frequently, the higher cognitive load of maintaining a decent relational model is simply not worth it.
Minimizing storage footprint was important, but the main selling point was data integrity, or at least data consistency. In large organizations, databases are still the most common point of integration between applications, and even those that are only accessed by a single application tend to outlive them as requirements and technologies change.
"Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity"
Well, foreign keys are not just a way to minimize storage: it speeds up future updates. If you duplicate your data everywhere for faster read access, your write cost just increased.
MongoDB is not the new MySQL, because software with as much inertia and adoption as MySQL will not see easy or even complete replacement. Case-in-point: IE6. IE6 is still with us today, as much as we hate it. You can make all the arguments for a modern browser that you want, but businesses and a few people say, "But I like it better."
Are there easy code migrations to MongoDB? No! Are there easy query migrations? Not really. It isn't a linear transition from one to the other. So no only do you have to rewrite your software, but you've got to pitch your SQL references out the window along with your queries.
I believe that Postgres will replace MySQL. It's mature, SQL-based and similar enough that only tweaks are needed to get a code base running. Oh, and it's free.
New projects may support MongoDB, but I'd be surprised if Wordpress ever came out with a version to support it.
i tried to explicitly make the point that MongoDB is not a replacement for MySQL, it is rather following a similar path from a licensing, usage and market reaction standpoint. and that mongo's course within the nosql world may follow the pattern we saw mysql track w/in the relational database market.
from this comment, it doesn't seem like i was successful on that score.
I think it's early to call a NoSQL winner/hammer now but I personally expected one eventually, http://www.quora.com/Will-there-be-a-new-de-facto-standard-o... although others aren't so sure. Just seems more convenient to use one database even if it's not an ideal fit for every task.
Not sure if I totally agree with the article, but MongoDB really is developer friendly: easy to set up and admin, slaves make create sources of analytics data (put a slave on each server that has analytics applications), useful for both large and small projects, etc.
Personally, PostgreSQL and MongoDB meet just about all of my non-graph data store needs. For graph data, I keep switching between Neo4j, Sesame, and AllegroGraph - can't make up my mind since they have different capabilities (Sesame and AG for fast indexed SPARQL queries, Neo4j for graph traversal).
The thing that I've found that makes MongoDB super easy for folks migrating from SQL is that it is easy to add indexes to arbitrary fields, and they work the same way as they do in MySQL. It's just a b-tree and if you can setup MySQL indexes, then you can build smart, well indexed structures and systems with Mongo.
Being able to do this without jumping all the way into writing map-reduce bits, but saving the time of setting up a rigid schema, makes it easy to see why MongoDB is so popular. To me, that is why MongoDB is the new MySQL.
I am confused. How hard is it to create an index in MySQL? I don't have much experience with MySQL, but with PostgreSQL, it is very easy.
In addition, there are some "advanced" features that may not be provided by MongoDB: you can choose your index type, rebuild the index, update the stats that will help the query optimizer decide if the index should be used at all, etc.
A decade later, MySQL – a feature-poor database relative to the commercial alternatives at the time – was the most popular relational database on the planet.
I would have thought the most popular relational database on the planet would be SQLite....since it ships with every android and iOS device, and with Firefox and Chrome.
I like and use both mongo and mysql. Where I think mysql shines is when you've been working on an applicaiton for 5 years, and end up connecting every piece to every other piece in ways you never imagined doing at the start. I think that's a lot trickier to do well in mongo, which favors denormalization since it's a document store. Given that most db's do not actually grow beyond what you can put on a single box, I suspect a lot of people may be avoiding problems they don't have while picking up problems they don't need by blindly switching to mongo.
That said, when you have a problem that mongo solves well, boy howdy is it nice.
The article doesn't describe but one of the biggest difference is scalability. MongoDB supports horizontal scaling as a built-in feature. It's known that MySQL can be scaled out by sharding but you lose ACID with it.
Of course scalability is required only when the service goes well. But it's important to considerate it if you intend to be successful.
It can be said scaled MySQL is a no-SQL. MongoDB is the New MySQL with this point of view.
According to the chart in the linked article (http://www.flickr.com/photos/sog/5909237515/), MySQL has had 73 (I assume distinct) committers in the past 12 months, but the most recent commit was over one year ago.
I'll admit that I'm not familiar with Ohloh, but I don't see how both of those statements can be true.
MySQL and MongoDB have strengths and weaknesses based on use case. MongoDB isn't a drop in replacement for MySQL and you probably wouldn't choose it for something like a message queue.
They're really different tools with different use-cases; I'm not sure it makes sense to directly compare them.
Redis is a fast key-value store with the nice property that values can be things like lists and sets instead of just plain strings.
MongoDB is a full-on document store for JSON-ish documents with support for complex ad hoc javascript queries over those documents, indexing, map-reduce style aggregation, and other fun arbitrarily complex search and collection scenarios that don't map into a simple key-value look up system.
[+] [-] KaeseEs|14 years ago|reply
On the bright side, one could say that at least half of the PHP/MySQL tag team has been improved significantly by being replaced with Python/MongoDB, as theological issues aside, Python is a lot less broken than PHP :)
[+] [-] sogrady|14 years ago|reply
that's an excellent - and much shorter - way of putting it.
[+] [-] 9oliYQjP|14 years ago|reply
http://www.paulgraham.com/opensource.html
[+] [-] va_coder|14 years ago|reply
MongoDB can be an excellent solution for professionals for many problems.
[+] [-] superuser2|14 years ago|reply
I see people angry about not using the "right tool for the job" all the time with regard to web applications. What other tools do you feel aren't used when they should be?
[+] [-] kennystone|14 years ago|reply
[+] [-] programminggeek|14 years ago|reply
Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity relative to many databases, so many devs don't care about only having one copy of a piece of data in the DB.
Also, SQL is great as a data retrieval language, but it is awful for inputting data. Yes, it works, but writing data to MongoDB in general has felt more natural than generating SQL to shotgun in data.
You could argue that ORM's solve a lot of the uglyness of inputting data into a DB and I agree with you, but you still have to deal with table migrations and being able to just add a field in your code and not have to go hold the database's hand or write a migration to make it work is incredibly convenient.
In the end, MongoDB solves a lot of convenience issues for programs that don't need relational data or programmers who don't want to use an ORM, create SQL strings, or write migrations to get their database to store their data.
It's not for everybody, but if it fits your needs, it solves some problems much more conveniently than MySQL.
[+] [-] IgorPartola|14 years ago|reply
However, I disagree with your other statements:
(1) we do not have infinite storage. Most data stores keep everything in RAM, and that is pretty limited.
(2) It's really easy to input data into SQL. There are in fact a bunch of methods to do so (almost all still rely on SQL).
(3) (more of a comment, than disagreement) ORM's don't solve much. They just remove the need for engineering a data access API and trade it for performance and cleanliness of code.
[+] [-] ahi|14 years ago|reply
One of my current projects is modelling a rather complex set of intertwined business processes. Part of the problem is just getting the client to explain their existing processes completely. Another part of the problem is that the processes are always changing. As soon as I think I finally have all the data models figured out, there's one more tweak. I am not great at data modelling or SQL, but tweaking a dozen 50 line joins on a daily basis is not happy fun time for anyone. At some point the specced data model, the model as implemented, and the conceptual model that's in my head get out of sync in some mysterious way, the plot is lost and it all turns to shit. On top of this I'm also trying to manage an object model that sorta maybe corresponds to the data model. In cases where the spec changes frequently, the higher cognitive load of maintaining a decent relational model is simply not worth it.
[+] [-] rubinelli|14 years ago|reply
[+] [-] St-Clock|14 years ago|reply
Well, foreign keys are not just a way to minimize storage: it speeds up future updates. If you duplicate your data everywhere for faster read access, your write cost just increased.
[+] [-] oldgregg|14 years ago|reply
[+] [-] trebor|14 years ago|reply
MongoDB is not the new MySQL, because software with as much inertia and adoption as MySQL will not see easy or even complete replacement. Case-in-point: IE6. IE6 is still with us today, as much as we hate it. You can make all the arguments for a modern browser that you want, but businesses and a few people say, "But I like it better."
Are there easy code migrations to MongoDB? No! Are there easy query migrations? Not really. It isn't a linear transition from one to the other. So no only do you have to rewrite your software, but you've got to pitch your SQL references out the window along with your queries.
I believe that Postgres will replace MySQL. It's mature, SQL-based and similar enough that only tweaks are needed to get a code base running. Oh, and it's free.
New projects may support MongoDB, but I'd be surprised if Wordpress ever came out with a version to support it.
Just my 2¢.
[+] [-] mechanical_fish|14 years ago|reply
http://www.flickr.com/photos/sog/5909237447/in/photostream/
If sociologists ran The Onion this would be on the front page.
[+] [-] andypants|14 years ago|reply
The x axis of the graph is unexplained, but the idea (of being able to measure sentiment) isn't crazy.
[+] [-] VilleSalonen|14 years ago|reply
I'm not saying that MongoDB isn't growing. I just think that it's way early to pronounce it as a replacement for MySQL.
These kinds of provocative but false titles belong in the cheap tabloids, not on the front page of Hacker News.
[+] [-] sogrady|14 years ago|reply
i tried to explicitly make the point that MongoDB is not a replacement for MySQL, it is rather following a similar path from a licensing, usage and market reaction standpoint. and that mongo's course within the nosql world may follow the pattern we saw mysql track w/in the relational database market.
from this comment, it doesn't seem like i was successful on that score.
[+] [-] Detrus|14 years ago|reply
http://hntrends.jerodsanto.net/?q=MongoDB%2C+MySQL%2C+Redis%...
I think it's early to call a NoSQL winner/hammer now but I personally expected one eventually, http://www.quora.com/Will-there-be-a-new-de-facto-standard-o... although others aren't so sure. Just seems more convenient to use one database even if it's not an ideal fit for every task.
[+] [-] sogrady|14 years ago|reply
http://www.google.com/insights/search/#cat=0-5&q=mongodb...
[+] [-] Joakal|14 years ago|reply
[+] [-] mark_l_watson|14 years ago|reply
Personally, PostgreSQL and MongoDB meet just about all of my non-graph data store needs. For graph data, I keep switching between Neo4j, Sesame, and AllegroGraph - can't make up my mind since they have different capabilities (Sesame and AG for fast indexed SPARQL queries, Neo4j for graph traversal).
[+] [-] Joakal|14 years ago|reply
[+] [-] mikey_p|14 years ago|reply
Being able to do this without jumping all the way into writing map-reduce bits, but saving the time of setting up a rigid schema, makes it easy to see why MongoDB is so popular. To me, that is why MongoDB is the new MySQL.
[+] [-] St-Clock|14 years ago|reply
In addition, there are some "advanced" features that may not be provided by MongoDB: you can choose your index type, rebuild the index, update the stats that will help the query optimizer decide if the index should be used at all, etc.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] marshray|14 years ago|reply
Now what's the next PostgreSQL?
[+] [-] aeden|14 years ago|reply
[+] [-] hasanove|14 years ago|reply
[+] [-] someone13|14 years ago|reply
* = For a certain value of "forever"
[+] [-] SigmundA|14 years ago|reply
[+] [-] dgrant|14 years ago|reply
[+] [-] josephcooney|14 years ago|reply
A decade later, MySQL – a feature-poor database relative to the commercial alternatives at the time – was the most popular relational database on the planet.
I would have thought the most popular relational database on the planet would be SQLite....since it ships with every android and iOS device, and with Firefox and Chrome.
[+] [-] josephcooney|14 years ago|reply
[+] [-] tedsuo|14 years ago|reply
That said, when you have a problem that mongo solves well, boy howdy is it nice.
[+] [-] frsyuki|14 years ago|reply
It can be said scaled MySQL is a no-SQL. MongoDB is the New MySQL with this point of view.
[+] [-] stevemoy|14 years ago|reply
I'll admit that I'm not familiar with Ohloh, but I don't see how both of those statements can be true.
[+] [-] shapeshed|14 years ago|reply
[+] [-] antihero|14 years ago|reply
[+] [-] msbarnett|14 years ago|reply
Redis is a fast key-value store with the nice property that values can be things like lists and sets instead of just plain strings.
MongoDB is a full-on document store for JSON-ish documents with support for complex ad hoc javascript queries over those documents, indexing, map-reduce style aggregation, and other fun arbitrarily complex search and collection scenarios that don't map into a simple key-value look up system.
[+] [-] sigzero|14 years ago|reply
[+] [-] sogrady|14 years ago|reply
[+] [-] nwmcsween|14 years ago|reply