6 ms·

Ask HN: Should I not use MongoDB?

• mattbillenstein 9y ago
  HN skews very anti-mongo, but it can be a good fit for certain apps -- I would stick with what you know until you think you've outgrown what you can do without sharding. I'd probably never shard mongo, but if you can vertically scale it for awhile, I'd do that. If you're on ec2, the i3 instances have very fast nvme instance storage at a reasonable (cloud) price.
  • rubyfan 9y ago
    I agree with the sentiment. Don’t refactor unless it’s failing you. Just be mindful you might refactor someday and backup your data.
    • nikkwong 9y ago
      Sounds good to me. I looked into sharding in the past but never took the leap as it added tons of complexity. Thanks so much!
  • gerenuk 9y ago
    What would you suggest instead of mongodb for large scale production db? Our DB size is growing on daily basis and currently near to 200GB on a dedicated machine.
    • brianwawok 9y ago
      Postgres or cassandra depending on scale and use case.
    • mattbillenstein 9y ago
      It depends -- if it's analytics, I'd look to ship it to a hosted system (I like BigQuery). If it's not, you might be able to scale up to terabyte or two before sharding; then maybe cassandra or one of the sharded postgres things (Citus, postgres-xl?)? I haven't had that problem in awhile.
    • richardknop 9y ago
      Depends on data. If it's time series data then I would use time series database like InfluxDB. But again you might be fine even with Postgres or Mongo. Depends on structure and type of data.
• smt88 9y ago
  The hatred and fear of Mongo is justified. That doesn't necessarily mean you need to switch right now. If you're just using a document DB instead of a relational DB, you won't have a hard time moving away from Mongo. There just isn't that much to learn. Even better, there are various databases that actually have Mongo compatibility[1][2], but internally will be more reliable and scalable. If you have the dev bandwidth, look into switching now and maybe give it a try in your dev environment. 1. https://www.torodb.com/ https://www.torodb.com/ 2. https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-introduction https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-int...
  • nikkwong 9y ago
    Great. I haven't built anything yet so I could just start out with one of these from the start. Thank you so much!
    • rlmongo 9y ago
      I would err on the side of caution with these so-called MongoDB-compatible databases. Most of them (such as Cosmos DB) only really support basic CRUD operations and none of MongoDB's advanced indexing and querying capabilities (such as MongoDB's aggregation framework cf. https://www.mongodb.com/presentations/webinar-exploring-aggregation-framework https://www.mongodb.com/presentations/webinar-exploring-aggr...)
  • jd_mongodb 9y ago
    'Hatred and fear" ? This is a database we are talking about? Companies all over the globe are betting their businesses on MongoDB and succeeding. e.g. most recently Ticketek http://www.theaustralian.com.au/business/technology/mongo-migration-just-the-ticket/news-story/fa3356b5ac731fa606b1bfa6252ab218 http://www.theaustralian.com.au/business/technology/mongo-mi...
    • jaydestro 9y ago
      mongodb employee here https://www.mongodb.com/who-uses-mongodb https://www.mongodb.com/who-uses-mongodb I don't see a ton of hatred and fear from Cisco, Facebook and Google. I dig what they've done, especially facebook, with MongoDB. Reconsider 2012 opinions and read about 2017's MongoDB.
• scalesolved 9y ago
  "Now that we're figuring out the technology stack for this, I don't want to do work that is going to have to be redone later." You're worrying about problems that you don't yet have and at scales you may never reach. I'd say stick with what you know and see if you can get initial traction with your users. If your data is highly relational then yes it's not a great fit but it's still passable if you're happy to give up transactions and the ability to force data consistency etc. Where I work we have a production API serving thousands of websites that uses Mongo, don't sweat the details too much early on.
  • nikkwong 9y ago
    Yeah, I feel like through using Mongo I've learned how to model my data in ways that are not relational, which has worked well because using aggregation at all always tends to be really awkward. Agreed that it could go no where, but, I'm hoping that one project, at some point in my life does well—so learning a technology that doesn't suffer from scaling issues would hopefully be a road I eventually have to take. Appreciate the feedback!
• jaydestro 9y ago
  hey there, i am a person from mdb: one thing i should express, many of the negative sentiments of mongodb are related to outdated facts or commentary. review some of the new features to ensure you're getting all the benefits mongodb has produced since the days of 2012.
  • brianwawok 9y ago
    So? Its still not a great product. People use it because they don't know better. Those that know better dont use mongo.
  • dsirola 9y ago
    That's not the problem in my opinion. The problem is advertising any kind of document DB as a general purpose storage. If you have a use case of making different aggregates from data, you'll have a bad time duplicating data or creating your own consistency layer.
• kenwalger 9y ago
  MongoDB is definitely ready and capable of handling your traffic. There are best practices to follow, however, as is the case with any deployment. I would concur with mattbillenstein that HN definitely skews anti-mongo. There are many, many companies using MongoDB very successfully. I have found that "issues" being reported with MongoDB are based on old versions and information, or an improperly configured and tuned environment. I recently wrote a blog post covering some topics around this. I'd encourage you to read it: https://www.kenwalger.com/blog/nosql/mongodb/mongodb-performance-issues/ https://www.kenwalger.com/blog/nosql/mongodb/mongodb-perform... I think you'll find that MongoDB will meet, and exceed, your expectations for performance.
  • nikkwong 9y ago
    This is very reassuring, thank you so much!
• giaour 9y ago
  Running your own Mongo instance will probably be fine for now. I remember Mongo administration being a massive time sink, but it only gets truly hairy when you need to shard and cluster. You can always use a hosted Mongo instance or a hosted Mongo-compatible solution like CosmosDB.
• mikegray831 9y ago
  Another user of MongoDB here. Thus far it has scaled well for us where we had a similar situation where uptake was faster then expected. The WiredTiger storage engine made most of the concerns of 2012-2013 for MongoDB, non-issues. However, if you try to put a relational model in to MongoDB, you still may see performance issues down the road, but then again it should be about the right tool for the right job. I'd reiterate Ken Walger's post to checkout his blog, it does a great job of comparing MongoDB 2012 vs. MongoDB today. Also, if administration/operations are a concern, then cloud provided MongoDB is the way to go, MongoDB Atlas seems to be at the forefront since it's run by MongoDB itself. Good luck with your apps!
  • nikkwong 9y ago
    Thanks so much! We currently use Atlas and it's been pretty great, although prohibitively expensive for my small side projects, where mLab instead has been awesome.
    • rlmongo 9y ago
      Are you aware that MongoDB Atlas has a free tier too? (https://www.mongodb.com/blog/post/announcing-free-tier-and-live-migration-tool-for-mongodb-atlas https://www.mongodb.com/blog/post/announcing-free-tier-and-l...)
• twobyfour 9y ago
  Mongo is the right tool for some jobs, but it's a poor choice for many. I recommend you learn at least one alternative database paradigm (relational/SQL databases are probably a good choice) so that you can make informed decisions about the trade-offs between data stores each time you start a new project.
• johnpython 9y ago
  MongoDB is the wrong choice 99.9% of the time. Just use Postgres.