8 ms·
Never, ever, ever use MongoDB
- svisser 11y agoNot even a hackathon?
- arthurcolle 11y agoIf your data really doesnt matter you might as well just use ElasticSearch as a document store, its a lot easier anyways
- lemevi 11y agoI doubt ElasticSearch is easier to set up and get started with than MongoDB, especially if you're coming from limited knowledge about either.
- fiatjaf 11y agoUse Redis, then.
- arthurcolle 11y agoWhy?
- EugeneOZ 11y agoActually Redis is as safe as PostgreSQL. Read the documentation please :)
- saryant 11y agoElasticSearch is trivial to set up, especially if we're talking about a small project like a hackathon. It's not without its problems but ES's first-fifteen-minutes story is pretty good.
- arthurcolle 11y agoElasticSearch takes less than 5 minutes to set up, and you literally just perform HTTP requests against it. In my opinion it is much easier than setting up MongoDB.
- meesterdude 11y agoES is wicked easy to setup and use, but it's not recommended as the primary data store for split-brain scenarios, IIRC.
- arthurcolle 11y agoOP was talking about hackathons.
- stickfigure 11y agoI've built real-world products with both ES and Mongo as primary datastores. ES is a hundred times more complicated, with a really awkward query syntax and a lot of unintuitive behavior. And, from the Call Me Maybe series, ES is no more reliable than MongoDB in a cluster. ES is amazing for what it does, but its use cases don't overlap heavily with Mongo (or RDBMSes).
- lucasmullens 11y agoThey've sponsored tons of hackathons, so it's super popular there. But to me, a big part of hackathons is learning something new, and MongoDB is apparently just not worth learning.
- joepie91_ 11y agoThis points at a bigger issue, to be honest: it seems MongoDB is popular purely because of marketing and intentional hype. Evidence for those claims that MongoDB is "fast" never materialized, nobody really knew where the claim came from, yet it was constantly repeated. They sponsor a lot of hackathons, and so on.
- giaour 11y agoMongoDB has THE WORST vendor lock-in imaginable, so only use it if you know that you could throw everything away. Source: my last employer used MongoDB, and switching to an RDBMS would have forced us to rewrite ~80% of the codebase.
- sshb 11y agoAbout 80% rewrite: it is poor abstraction problem rather then vendor lock-in one
- giaour 11y agoYeah, that contributed, but it wasn't any worse than most other CRUD apps I've seen.
- cwyers 11y agoAbstracting over your database only makes sense if you're writing something that's lowest common denominator. If your application runs equally well on MongoDB and something else you either are running poorly on both or you are spending a lot of resources on writing your abstraction layer.
- deleted 11y ago[deleted]
- oliyoung 11y ago"you know that you could throw everything away" To be fair, that's like 99% of all hackathons I've been to
- lemevi 11y agoHow would one use Meteor.js without MongoDB though? Are you saying not to use Meteor.js too? I was thinking about maybe toying with the idea of making a fully reactive RethinkDB package for Meteor.js.
- jxm262 11y agothere's a card on trello asking this for a future enhancement (I haven't followed the discussions for a while though). https://trello.com/c/Gf6YxFp2/42-sql-support https://trello.com/c/Gf6YxFp2/42-sql-support However, I believe there's a few existing options for using postgres - https://github.com/numtel/meteor-pg https://github.com/numtel/meteor-pg http://www.meteorpostgres.com/ http://www.meteorpostgres.com/
- deleted 11y ago[deleted]
- davnicwil 11y agoYou don't. In fact it's the reason I'm not using Meteor, which is a shame because it looks really good. The optimistic UI feature is something I really want, and have had to implement my own custom solution for. I've nothing against Mongo per se, I just need a relational database. Since most apps are likely better suited to using a relational database, I'm curious as to Meteor's original decision to go with Mongo. Would love to know their rationale behind that choice if anyone can enlighten me / point me towards any articles?
- justizin 11y agoDefinitely never use a technology that's married to a single backend.
- mark_l_watson 11y agoI recommend setting aside these scare stories about mongodb after you read the instructions on how to check that writes succeed, and look into replication. Sure mongodb has its problems but a few years ago I helped a customer run mongodb at very large scale. Meteor.js is a fantastic development system (if you can live with needing sticky sessions and you need its features).
- _pdp_ 11y agoI, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. I've got nothing against relation databases but there are not a solution to every single problem. Heck, why not decide first if you can use flat files? Do you really need to query and join. Not all problems require that sort of thing.
- joepie91_ 11y ago> I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. The issues I listed provably exist. That you haven't run into them yet doesn't change that - and quite likely, you might not even know whether you've run into it. Losing data or having your database open to the wide internet, for example, are two scenarios that you will likely not be aware of unless you explicitly test for them. > I've got nothing against relation databases but there are not a solution to every single problem. And if you'd read my post carefully, you would've seen that I make no such claim. They do solve many problems, however. > Heck, why not decide first if you can use flat files? Flat files are rarely the correct solution. Race conditions ahoy! > Do you really need to query and join. Not all problems require that sort of thing. Many do. And even if they don't, MongoDB is still not the right choice.
- foobarian 11y agoIf nothing else psql has a nice tabular output. Sometimes I go out of my way to import something into a local pg instance just so I can format things using psql.
- facetube 11y agoPostgres 9.4 even has `jsonb` and GIN indexes, which in a lot of ways provides nicer schemaless storage than some of the NoSQL databases provide. You're also free to mix in traditional relational tables (since `jsonb` is a data type like any other), or even efficiently join two tables based on a JSON containment operator. I haven't looked in to it _too_deeply, but what I've seen so far looks really neat.
- fiatjaf 11y agoI think people only use it because it stores JSON and let's you query it arbitrarily on demand. It appears to be as good as CouchDB, but with on-demand queries, as good as Postgres, but with JSON (!). It appears to be quick and easy and the tool for the job. Also, when people say NoSQL they actually mean MongoDB.
- imaginenore 11y ago> Also, when people say NoSQL they actually mean MongoDB That's just not true. There are tons of NoSQL solutions that are well known. Redis.
- bpicolo 11y agoIn fact it's quite literally the opposite of true. Edit: In the sense that there are many, many well-regarded and used NoSql databases.
- giaour 11y agoCassandra, Couch, Redis, Riak, Dynamo...
- arthurcolle 11y agoPostgres, MySQL, RethinkDB...
- fiatjaf 11y agoRight, I know that, but thank you for listing.
- TheHippo 11y agoOr: You could just RTFM and avoid all these issues. For example: The message warning you that 32bit builds are not safe for storing more than 2GB of data is larger than the download button itself. If don't see this, you should probably be not in charge of storing any data anyways. Many other issues have been resolved with the 3.0 release or are documented very clearly.
- joepie91_ 11y ago1. There was no such warning for a long, long time. 2. It's a dumb limitation, and an architectural issue as far as I'm concerned. 3. It still doesn't justify silently throwing away data for years. 4. Many of the points on my list remain unaddressed, and likely never will be addressed. EDIT: Additionally, the typical system administrator doesn't install MongoDB from the 'Downloads' page, but uses a package manager, and thus never sees the warning even if it's there. Warnings like this belong in all the relevant spots in the documentation, not just on a download page.
- yousoundmad 11y agoyousoundmad
- cheald 11y agoThat 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a014683018ac81c30df0b0823bf03272 https://github.com/mongodb/mongo/commit/b3322b86a014683018ac... There's plenty in Mongo to complain about, but grousing about the 32-bit limitation just makes you look like you're bad at reading introductory documentation.
- joepie91_ 11y agoThis doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongodb.org/downloads https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of initscripts and such). It should have been in all the relevant places in the documentation, instead.
- iagooar 11y agoBeen there, done that. Spent over a year trying to make Mongo behave like a decent DB, and it would still fail to do so. Actually, I wrote a small "goodbye letter" to MongoDB on HN in the past: "You got your chance, Mongo, and you screwed it up. I tried getting the most out of you. I treated you like a princess, I indulged you, your wishes became my wishes and your thoughts were my thoughts. I stopped listening to all that criticism around you and thought of you as of a misunderstood child, even as you would refuse to do even the easiest tasks one could imagine. I gave you everything there is to give, but you broke my heart. You left me in the most critical moments. I trusted you, but you would go your own way. Tears were shed and countless sleepless nights were to follow. Remember that night you disappeared without leaving a sign? I sent you messages which got a response only after many hours. You didn't give a damn about my needs. Once, you told me: "it's not me, it's you". And I believed you, I truly did. It's over now. It's been some time without you, and I'm getting better. I have discovered, that not everyone is like you. Some DBs care, they really do. You can trust them, they give you their everything. I'm still struggling falling in love again, but it's getting better. Don't write me back. Goodbye." Here's the link: https://news.ycombinator.com/item?id=8990754 https://news.ycombinator.com/item?id=8990754
- deleted 11y ago[deleted]
- Animats 11y agoIf your site has less traffic than Wikipedia, use some relational DB. If your site has more traffic than Wikipedia, you already have a dev team that understands big data.
- karmakaze 11y agoNow with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is better suited than BSON). For any other use CouchDB.
- threeseed 11y agoThere are a few. Mongo has excellent integration with Hadoop and is becoming very popular in the big data analytics space. Likewise it is gaining traction in the EDW space as a result of their partnerships. Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.
- CHY872 11y agoAs simple as sqlite with a decent ORM? Just curious here, I've never tried Mongo.
- joepie91_ 11y ago> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes. It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'. In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have your database broken into (if it can even be called that, without authentication), or you end up corrupting your data because two of your applications disagree over what the current object schema is. To know how easy something really is, you need to compare how hard it is to set something up correctly. And once you do that, MongoDB falls far behind.
- djacobs 11y agoI'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.) Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.
- toyg 11y agoI've used MongoDB recently for the first time, for an internal project. Being schemaless, I believe it did speed up development time significantly, and allowed me to add stuff more gradually, but you could say that's just a way to indulge a certain laziness of design. Now that the project has matured, stepping back I can see how a relational database would be a better fit, but if I had used a rdbms from the beginning I might have not "shipped" quite as quickly. Swapping it out for a real rdbms will mean changing a couple of classes anyway, nothing dramatic. So uhm, I don't agree that it's not good for prototyping; if your final code ends up having a decent abstraction level, it should not matter what you picked on day 1 anyway.
- jimbokun 11y agoThe article mentions CouchDB and other schematic-less, document DBS, which should be equally good for prototyping but suck less.
- cwyers 11y agoI don't understand why a schemaless database is so great for prototyping. Most of the pain from schema changes is when you have a lot of code or a lot of users depending on an existing schema, so it's hard to change (or at least, hard to change while maintaining uptime). Running ALTER TABLE on a small dataset with almost no users is trivial.
- toyg 11y agoIt might be trivial but it's another thing to do, which is is simply not there otherwise.
- rdtsc 11y agoSchemaless is just one aspect the other one is clustering/replication. Not sure about MongoDB but CouchDB has master-less peer to peer replication built in. That is hard to bolt-on later on top of Postgres and other databases. Just saying that is another factor in play, not just schema vs no-schema.
- nailer 11y agoRelationships in MongoDB are commonly stored as ObjectID references, and (at least on node) the default Mongo client (Mongoose) makes you write schemas to enforce these. I think Mongo is awful too, and I'm sure there are problems with this approach - I'd love for someone with more DB knowledge to go into details - but saying there are 'no relations' seems to be an oversimplification.
- phillips1012 11y agoMongoose isn't the default Node.js MongoDB driver, though it is very popular.
- joepie91_ 11y agoMongoose is a client-side library. It emulates relations and schemas client-side, as I also pointed out in the article.This also means that the database cannot optimize for relations and schemas, as it doesn't even know they exist. Mongoose is also very much not the default MongoDB client in Node.js - it's a third-party client library by Automattic. The official client according to the MongoDB documentation is `mongodb` (https://www.npmjs.com/package/mongodb https://www.npmjs.com/package/mongodb), which does not feature relations.
- nailer 11y agoI have used and am aware of node-mongodb-native (I wrote http://stackoverflow.com/questions/19546561/node-mongodb-error-connection-closed-due-to-parseerror/19546605#19546605 http://stackoverflow.com/questions/19546561/node-mongodb-err... where we discovered it wrapped and threw away all exceptions in callbacks in the stable production version ), but Mongo (the company) have recommended Mongoose. The language now is vaguer than it was 'you can use it natively if you want, or use Mongoose' http://docs.mongodb.org/ecosystem/drivers/node-js/ http://docs.mongodb.org/ecosystem/drivers/node-js/ Thanks for your excellent explanation and totally understood re: not being able to optimise for relationships on the server.
- joepie91_ 11y agoI actually didn't even notice Mongoose being mentioned on that page, to be honest, given that the instructions were for `mongodb`. I'd imagine that neither would a developer skimming the page :)
- jqm 11y agoI did the MongoDB class they offer but was always scared to use in production (after reading so many bad experiences). And it's really too bad. I find JSON is just so much more pleasant to deal with than SQL.
- bsg75 11y agoApples and oranges. JSON is a format (Object Notation), SQL is a query language. Some databases support queries of JSON structured data using SQL.
- jqm 11y agoSure. But I'm just stating which I'd rather deal with. Not claiming equivalency.... Does MongoDB allow SQL queries? I didn't know that, but then again, I guess I don't care either. I haven't looked at Mongo in a couple of years after deciding not to use it. I do recall liking the query syntax from the class though. I haven't messed with JSON features in PostgreSQL yet and have no idea how they work. That's next.
- nailer 11y agoIf you like laptop stickers: https://pbs.twimg.com/media/CF9XvchWYAEKzTp.jpg https://pbs.twimg.com/media/CF9XvchWYAEKzTp.jpg Source .sketch file is in: https://github.com/mikemaccana/stickers https://github.com/mikemaccana/stickers Joke is Alex Sexton's, I licensed font, designed, and printed them. Apparently a couple have found their way to Mongo HQ.
- tonymillion 11y agoThis entire article in one tweet: https://twitter.com/tonymillion/status/417213069572714496 https://twitter.com/tonymillion/status/417213069572714496
- PebblesHD 11y agoAs a smaller setup that requires far less traffic than a large scale real-time application, what are the draw backs of just using a basic MySQL installation? We've hit over 20k views per day on our internal wiki with no signs of even coming close to any limits with either our hardware or the SQL stack.
- dogweather 11y agoMongoDB is awful for development. I once started consulting on a Rails app project which used MongoDB. But I was never able to get productive: I had my development environment all set up, but then the code wouldn't work with the development database. I pinged the other dev: "Oh, I made changes to the data model. I'll zip up and email you a new copy of the dev database." This continued for a couple of iterations and I had to quit the project because I could never continuously get work done.
- berntb 11y agoI'm ambivalent to MongoDB, because I think that too often you'll find out later that you really, really need joins for something anyway. But your painful problems seems more like a problem with communication/documentation practices. DB changes will occur with SQL databases. It is about equally important to communicate them to other users of the DB. (But OK, it is easier to find the changes with an SQL DB.) (Yeah, I'm hellbanned.)
- CmonDev 11y agoI thought it cannot get worse than dynamic languages, but then they invented document databases.
- vhogemann 11y agoIf you're trying to use MongoDB as a relational database, and don't understand its limitations and strengths, of course it will be terrible. MongoDB is good if: a) Your data model fits into the document model. Usually that means you'll be querying only one collection at time. b) The access pattern of your application is a lot of READs and few writes. MongoDB has a collection lock, so it sucks for concurrent read/write operations. c) If you need ACID support, your operations must be restricted to a single document. If your problem fits on the restrictions above, you probably won't run into many problems. We've been using Mongo to store our authentication info, and to store payment transactions. No major problems so far, but our needs fit nicely into what MongoDB can provide. Most of the rants I see are from people that got burned trying to use MongoDB as a drop-in replacement for a relational database.
- sweetiewill 11y agoI actually started learning NoSQL on MongoDB but later switched over to CouchDB and never looked back since. Seems like a lot of other companies are too (Eg. Viber) Here's a video from their tech team explaining the reasons behind the switch: https://www.youtube.com/watch?v=R5JpRrMJVIA https://www.youtube.com/watch?v=R5JpRrMJVIA