14 ms·

Ask HN: Do you still use MongoDB?

• econcon 6y ago
  How are you guys monitoring mongodb instances in Google Cloud?
• franciscop 6y ago
  I haven't used it for a while and I've been planning on learning Postgres after much praise from a friend (and the internet at large). I find DB design and migrations quite difficult though, any book/course recommendation?
  • Beefin 6y ago
    https://university.mongodb.com https://university.mongodb.com
  • takeda 6y ago
    I don't have a specific book for you, I myself learned about relational databases at school, not sure why is not being taught everywhere. The things that you have problems with aren't really specific to PostgreSQL so if you are looking for a book while one based on PostgreSQL might be easier, there might be better books that talk about relational databases and what you learn will still apply. About migrations, from PostgreSQL point of view you just use ALTER TABLE, CREATE INDEX, DROP INDEX etc. it's fairly trivial. The problem comes that developers want to have it version controlled. So a framework around it is often built. Typically that functionality comes with whatever framework you are planning to use. For example if you use Python and Django framework it comes with migrations functionality, so you just learn what the framework provides.
    • franciscop 6y ago
      I studied a different Engineering, not CS, so never really had any course (besides basic C). I've read quite a bit and understand the normalization forms, but it's more from a practical sense. What data should we include, how to structure it so that it's not too complex, but doesn't come back biting me, etc. A good example (but not only!) is login. You can have just user session, or session+token in DB, or session + devices (1 active token/device), etc. So maybe seeing business problems and how the DB was structured to help would be the best here. > The problem comes that developers want to have it version controlled. Oh maybe that's the reason I found those so tricky. I don't explicitly care about VCS, but I definitely care about migrations going wrong, and hopefully being able to revert if it goes wrong. Maybe if I get myself comfortable enough with manual migrations this is not such a huge topic though.
      • takeda 6y ago
        When structuring data you generally want it to be in 3rd normal form or higher. The normal forms the higher you go the less duplication you have in your data, but then the more joins you will do and that could reduce performance. > A good example (but not only!) is login. You can have just user session, or session+token in DB, or session + devices (1 active token/device), etc. So maybe seeing business problems and how the DB was structured to help would be the best here. I think you're overthinking it a bit, besides I don't know if you're saying it but in case you are, you don't want to mix login information (like user account, name, login password etc) with a session. Those things are separate and have different requirements. For example let's say your site became so popular that you have scaling problems. It is perfectly fine to take the session and put it in nosql store, or (maybe even better) in a cache. This data is accessed on key/value basis and also while not great it won't kill you if the data disappears due to some outage (users just get log out). As to what you store there, session + device or session + token in DB is purely based on your need. Frankly I don't know what you mean by token in DB, in fact I'm not sure what do you mean session + device either. Sessions generally is a randomly generated ID that tied to a session, if user connects from a different device they will have another session anyway. I don't think this particular thing is something that relational database dictates. But you generally wouldn't want to place sessions in user table. Those two things are completely different even when they seem to be related. You should have separate users table and separate session table (most frameworks handle sessions for you, so you might not even need to think too much about it) > Oh maybe that's the reason I found those so tricky. I don't explicitly care about VCS, but I definitely care about migrations going wrong, and hopefully being able to revert if it goes wrong. Maybe if I get myself comfortable enough with manual migrations this is not such a huge topic though. In PostgreSQL (it might not be true in other databases) DDL (Data Modification Language) can be inside of a transaction. So you can start a migration with "BEGIN" and then check if what you did worked fine before you say "COMMIT". Note though, when I said developers want to have it version controlled. They do that to avoid any mistakes. Such as forgetting the BEGIN, or accidentally pasting wrong thing to the shell. So if you have a production data you absolutely should use them. But if I were you I would first try to learn it by doing it by hand on a test database. If you understand what is actually done the migrations don't seem that magical.
• gjmacd 6y ago
  Someone needs to explain to me what the benefits of NoSQL with MongoDB are when you have the JSONB column type and the ability to query and insert at the field level with JSON in PostgreSQL? Maybe there's some benefit, but I'm not seeing that major "gotta have it" feature or performance gains. And I ask this question seriously, because I just don't know the answer.
  • amerkhalid 6y ago
    Having to work with MongoDB, I say only benefit is you don't need to plan or think through your design. Which in my view is not really a benefit. You end up checking for null properties everywhere.
    • jonnypotty 6y ago
      Most of the positives here seem to be "it's easy". Someone said they had to manage their indexes on it, which was bad. We can't just keep relying on super fast hardware and magical software to get us out of having to think.
  • nemothekid 6y ago
    >Someone needs to explain to me what the benefits of NoSQL with MongoDB are when you have the JSONB column type Schema-less design is a feature of MongoDB, not NoSQL, but has unfortunately has persisted as one of the "benefits" of NoSQL. However when you look at the top 5 "NoSQL" databases on db-engine rankings only 2 support "JSON", MongoDB and Elasticsearch. The rest are key value, or require schemas (Cassandra). The appeal of NoSQL, to me, has been the scale out to tens, hundreds or thousands of machines relatively easily. This is where Postgres does not shine, and this is the only reason I'd choose something as binding as DynanmoDB over something like Postgres.
• billconan 6y ago
  yes. Because we scrape data from different websites, and they each has very a different content format. mongodb handles unstructured data well
  • TomMarius 6y ago
    Have you compared with postgresql's jsonb?
    • Beefin 6y ago
      jsonb is limited in it's querying capabilities. you're essentially casting the json as a string when storing and querying, it's not truly json. therein lies the advantage of document model, native secondary indexes, $<queries> for everry nested layer, etc.
      • indigo945 6y ago
        Postgres's jsonb format is definitely not "essentially" a string. You can get native indexes on json fields in Postgres, and you can query fields however you like.
        • Beefin 6y ago
          https://www.postgresql.org/docs/9.5/functions-json.html https://www.postgresql.org/docs/9.5/functions-json.html they are surrounded by quotes, is that not a string ?
          • indigo945 6y ago
            If a man is surrounded by trees, does he become a grove?
          • fabian2k 6y ago
            Those are json literals in the SQL query. That has nothing at all to do with how json is stored in jsonb columns in the database itself.
• colinbartlett 6y ago
  No. I only ever used it previously for things like logging unstructured API responses. Now I just shove that kind of stuff into PG JSONB.
• gas9S9zw3P9c 6y ago
  I use postgres for pretty much everything these days, sometimes with Hasura if I need GraphQL. There was a short period of time (1-2 years or so?) where I did my projects with Mongo, but right now I don't see what it can offer over something extremely stable like postgres, which also handles JSON amazingly well.
• stavros 6y ago
  No, I had a sour experience in 2009 where it ate my data, the devs were rather cavalier with "there's a warning on the download page" (I got it through apt), it ate my data again when the OOM killer killed its process. I didn't like the project attitude of a database being so lax with persistence, so I never used it again.
  • nailer 6y ago
    I'm the most popular non-MongoDB-employee answer at 'to what extent are 'lost data' criticisms still valid of MongoDB?' My answer contains a history of my experiences with MongoDB that is pretty similar to yours: https://stackoverflow.com/a/18269939/123671 https://stackoverflow.com/a/18269939/123671 I feel like MongoDB now is actually a pretty stable product simply through time and investment, however I will never trust the company for using our data to beta test for a decade.
    • StavrosK 6y ago
      That's my attitude as well. RethinkDB, in comparison, had a much better attitude of "reliable first, fast later". Unfortunately, it turned out that when you're a database, it doesn't matter how much data you lose, only how fast you are while losing it.
      • asah 6y ago
        The PostgreSQL community is a nice counterexample - perfectly gigantic and growing marketshare, and very very reliable.
        • StavrosK 6y ago
          PosgreSQL is amazing, I use it everywhere. SQLite is the only other datastore I love that much.
        • rat9988 6y ago
          Listening to the community and using Postgres is my biggest regret. In hindight, given our scale, any database would have worked. There is no built in solution for high availability with multiple VPS, and having one server alone isn't enough availability for me.
• pschlump 6y ago
  No - Postgres is faster and it has JSONB. (It also has tables and SQL and GIS and ...)
  • threeseed 6y ago
    Can you provide benchmarks showing PostgreSQL is faster ? Because from my experience MongoDB was at least 10x faster and all of the benchmarks I've seen were using pre-WiredTiger storage engine.
    • dajonker 6y ago
      There's no reasonable way to compare performance between PostgreSQL and MongoDB because they're not the same kind of product and they don't have a similar query interface. You can take a particular application and compare performance when using two different databases on the back-end, but then the database itself might not necessarily be your bottleneck, it might also be the way the application is written. Because the database is only a part of the equation, the comparison also doesn't tell you anything about the performance of any other application.
    • takeda 6y ago
      You can get amazing performance results if you don't care about data persistence. Anyway when postgresql introduced JSONB there was a benchmark for CRUD operations, can't find it now, because it was long time ago, but I remeber postgresql was doing circles around mongodb.
• adityapatadia 6y ago
  We use it extensively. Basically the low overhead and almost no maintenance requirement of startup world is nicely satisfied by Mongo. In our last 3 years of usage, we never faced any issues from DB. It's improved a lot in last 2-3 years and I can say it's rock solid right now. I am basically finding no reason to switch to any other DB.
  • quotha 6y ago
    What is your business/website ?
• ochronus 6y ago
  I've heard it's webscale! ;)
• jondubois 6y ago
  MongoDB is a pretty good database IMO. I've used it at several companies in the past and wouldn't mind using it again. My favorite DB is RethinkDB. It's a shame that the company behind it fizzled out and was absorbed by Stripe. I still cannot wrap my mind around why it's not more popular. It's similar to MongoDB but much better. It's the perfect database. It adds constraints which improve the quality of your code. Also RethinkDB scales very well and the control panel that comes with it is mind-bendingly powerful, I'm not kidding; you can click a button to shard or replicate a table over multiple hosts! WTF! I can't say the same about Postgres unfortunately. There is nothing truly remarkable about it. I use Postgres for one of my projects today but purely because of compatibility reasons with an existing system. I don't understand what all the hype is with Postgres.
  • qatanah 6y ago
    back when mongo was around 2.6x, they had a global write lock. Also, you'll encounter more problems with mongodb if in case you need transaction. You should check out more discussion here on db systems. http://www.redbook.io/ http://www.redbook.io/
    • threeseed 6y ago
      MongoDB 2.6 was released 7 years ago. Why are you bringing it up ? If you use MongoDB today then (a) there is no global write lock and (b) there are transactions.
    • jondubois 6y ago
      IMO I've come to see DB transactions as a hack because they limit scalability. It's possible to use two-phase commits instead. Two-phase commits can scale without limit but you have to be more careful when designing your tables and specifying your indexes. For tables which need atomicity, you can add a 'state' column/field which is either 'pending' or 'settled'. You can have a separate parallel subroutine (or process) in your code to handle settlement. You have to design it in such a way that if the system fails at any point, it will re-process all 'pending' entries in an idempotent way. It's a bit more work, but it scales without limit. You can add a shard key (or use account IDs) so that you can have multiple processes/hosts working in parallel to insert pending transactions and also multiple processes to settle them in parallel. In financial transactions, I would separate it into two parts: A debit entry and a credit entry which are initially inserted into the DB as 'pending'. The settlement routine will match them up together - Making sure to process/settle the debit side of the transaction first and only once the debit is in the settled state, it will process/settle the credit side. If the settlement engine sees any conflict (e.g. user tries to spend more money than they have by submitting many transactions in parallel), it will accept all the transactions as 'pending' but mark the later ones as canceled (they will not settle) so the credit entry will never be created on the other account.
• werber 6y ago
  I use it for small personal stuff because it’s easy for me to play with
• dejv 6y ago
  I am still using it for few legacy apps. I don't really love it but it it is rock solid for that payload: mostly just storing simple events. For new projects I just use Postgres, especially after they've introduced json datatype I don't have need for noSQL database for type of projects I am doing.
• deleted 6y ago
  [deleted]
• heipei 6y ago
  Yes, still using it for storing relatively unstructured blobs of JSON which I only lookup via key but update with various operators ($addToSet, $set, $incr). Also using it as a persistent session store and lately for storing rate-limiting information. I've come to like the MongoDB update operators and features such as the Change Events. However I will eventually be moving off MongoDB as I need horizontal scaling via shards, and the sharding setup of MongoDB is needlessly complex and brittle. Currently planning to go with ScyllaDB for my large-volume key-value blob datastore and some flavour of SQL for low-volume things which need more complex query behavior (user database, subscriptions). ScyllaDB will present challenges since I still want to have the ability to update single keys in big JSON blobs, even if my only lookup is by key. If MongoDB came up with a better sharding experience where every box is equal and you don't need the dance with shards on top of replica sets plus mongos plus config servers plus arbiters I might consider it again.
  • Beefin 6y ago
    Atlas makes sharding easier, it's just one button where you define your partition key.
    • heipei 6y ago
      No offense, but if I wanted to have managed MongoDB I might as well use AWS DocumentDB. I honestly believe that this is a key differentiating feature for many databases. ElasticSearch, ScyllaDB, others too work the same way: Every node is equal and in order to scale you just keep adding more boxes, end of story. Compare that with what you have to do with MongoDB.
      • Beefin 6y ago
        No offense taken haha DocumentDB is a great DB, but in the end of the day it's a forked version of 3.6-ish so it's missing a ton of new features like multi-collection ACID guaratneees. Plus, whenever you use DocumentDB you're accessing it via the MongoDB official drivers, so you'll be handling that compatibility mess yourself.
      • 6y ago
• hannob 6y ago
  I have never used MongoDB directly, but I can tell you since their license shenanigans I consider it toxic. Their "we will try some different form of Open Source (which really isn't open source at all, but we still want you to think so, because we know open source is popular) also AWS did something evil by using our software accoding to the license that we used for our software" thing really didn't inspire any trust.
• oneplane 6y ago
  Yes, still use it, together with GridFS. We mostly use it as a persistence store for SOAP message dumps from XML to JSON in Java; everything else usually resides in a Postgres or Aurora RDS database on AWS or some legacy Oracle/MSSQL stuff elsewhere (which we try to get rid of). The issue with most of this stuff is that a lot of projects just need some persistence and basic querying, and almost any database can do that equally fine. At that point, maintenance, ops workload in general or reliability are the differentiators and most of those go away when you run them as a service with your cloud provider of choice. Which specific one you use is practically selected for you: take all the ones that are compatible with your application or framework and sort by price.
• niffydroid 6y ago
  Yes, it's our main DB. I still like it quite a lot, we use Mongoose as ODM, it makes adding new stuff so much easier without having to do things like alter table etc. But for our big data stuff we use BigQuery, simple because of cost. I do like how easy it is to get a mongo instance up and running locally. I found maintenance tasks for mongo are much easier than postgres. One thing you still need to do is manage indexes for performance, I've had to spend many a days tuning these. I have come across some rather frustrating issues, for example a count documents call is executed as an aggregate call, but it doesn't do projection using your filters. e.g you want to count how many times the name 'hacker' appears. It will do the search against name, then do the $count, but because it doesn't do a projection, it will read the whole document in to do this. Which is not good when the property you're searching against has an index, so it shouldn't have to read in the document at all.
  • Beefin 6y ago
    why not just do a covered query with aggregate pipeline via $match and $project, hitting all your indexes, then pipe the results to $count.
• Beefin 6y ago
  Yes, use it with Atlas for every one of my companies' projects. - The document model is a no-brainer when working with JS on the front-end. I have JSON from the client, and Dictionaries on the backend (Flask), so it's as easy as dumping into the DB via the pymongo driver. No object relational mapping. - Can scale up/down physical hardware as needed so we only pay for what we use - Sharding is painfully easily, with one click - Support has been incredible
  • unixhero 6y ago
    This is a great testimonial. Would you care to share what Atlas is/which software package Atlas is?
    • Chris2048 6y ago
      They probably mean https://www.mongodb.com/cloud/atlas https://www.mongodb.com/cloud/atlas
    • zachruss92 6y ago
      Mongodb Atlas is their hosted DB as A Service. They will manage the infrastructure for you on any of the major cloud providers at a premium rate.
  • stevievee 6y ago
    I've used mongo before and I just started using Atlas. Anything you don't like about it?
  • abrookewood 6y ago
    I'd echo most of those sentiments, but not all: + Support on Atlas is good + Set up process is very streamlined and smooth + Modifications (scaling IOS etc) are all very easy, but ... - The Atlas web client had a bug that swapped data types (fixed, but still) - The database starts off fast, but seemed to get quite slow considering how small it was (fitted entirely in RAM) - The latest Jepsen report suggests t is still very cavalier with data integrity (http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6)
  • 6y ago
• ollysb 6y ago
  No, I inherited a project that was using it a number of years back. After 6 months we migrated away to postgres. The data was really relational so it was just the wrong tool for the job. I can see that it might have value as a document store but with postgres' json facilities these days it's hard for me to see a scenario where I'd choose it.
• josephg 6y ago
  No. Every time I've used mongodb we've ended up regretting it for one reason or another. And migrating to a different database after launch is a huge hassle. I've done a couple projects where we kicked off with postgres using JSONB columns for early iteration. Then we gradually migrated to normal SQL columns as the product matured and our design decisions crystallized. That gave us basically all the benefits of mongodb but with a very smooth journey toward classical database semantics as we locked down features and scaled.
  • heliodor 6y ago
    Yep, just regret and misery. Back in 2010 when the MongoDB hype was high, the well-known company where I was working at the time decided to build the next version of the product using MongoDB. I was on the analytics team and had to code a whole bunch of intricate map-reduce jobs to extract summary data out of Mongo. I'd repeatedly head to the product team and ask them to explain the edge cases I was seeing in the data and they would not be able to give me an answer because the data was on the third or fourth version of their mentally-stored schema and no one knew anymore. All in all, misery.
    • tmlee 6y ago
      While there are many people here who are sharing their bad experience with MongoDB, just curious if you all find the experience with DynamoDB similar? Since they are both of the NoSQL family.
      • gnulinux 6y ago
        I'm curious as well, since my company is moving from Postgres to DynamoDB.
        • john-tells-all 6y ago
          Could you share your use case?
      • garethmcc 6y ago
• joshuanapoli 6y ago
  No, we used MongoDB in 2009-2010 but it was a disaster as performance and integrity fell apart as our data-set grew. Maybe it’s OK now, but I see no reason to go back.
• drawkbox 6y ago
  MongoDB was only really ever a competitor to memcached, redis, others and really only good as a caching layer like those. It is decent for that. There was a time when JSON wasn't that integrated into databases, it is now. That was really MongoDB's killer feature. PostgreSQL does most of this better now and more robust/reliable.
• collinglass 6y ago
  Yes, we do at WaystoCap. It's our main DB. I like it mostly for the flexibility. I think it's one of the best DBs when you're in pre-product market fit stage and making a lot of changes to the data model. One of the main cons I've experienced with it, is it's beginner friendly nature and docs leads you to have a non-optimal data schema for No-SQL. Like even the way it does pagination with Skip, is not the performant way to do it. As areas in our business mature and scale we suffer bottlenecks and have pretty big changes to optimize those areas of the data model.
• speedgoose 6y ago
  I have not used it for years. I simply prefer relational databases after all. When a document database makes sense, it happens, I go with CouchDB. Its multi-primary architecture is attractive compared to MongoDB with a single primary node. But I'm thinking about using PostgreSQL and jsonb next time.
• LongHalloween 6y ago
  I am using it in production but I'd like to try PostgreSQL at some point, it seems to be the Rust of RDBMS, getting lots of love.
• pjmlp 6y ago
  I never used it and don't plan to.
• Hippocrates 6y ago
  Unfortunately. And devs are still doing triple lookups (joins) like they’re using sql, forgetting to add indices and designing/evolving schemas sloppily. Data is a mess and there’s an outage every few weeks. It’s also expensive af (probably due to improper use). It’s flexible when you’re trying to “get going” but creates pain later on. I like SQL because it is way more expressive and helps you answer questions you didn’t know you would have. I find that incredibly valuable. Pretty tough to do in mongo. Generally BQ is good for this (in addition to your app DB) but if you use mongo you’re gonna have a hell of a time stuffing that sloppy schema into any column-oriented dB. I like some of the serverless GCP dbs like datastore and firestore over mongo. They Index every field and force you to add composite indices on first query run by spitting out an error with a link to create it. If you understand their unique but simple API, limits, and quotas, they work predictably and scale nearly limitlessly.
  • myth2018 6y ago
    > I like SQL because it is way more expressive and helps you answer questions you didn’t know you would have That's precisely one of my points against using object-oriented approaches to model domain data in business-related, ERP-like applications. I always go for simpler data structures representing relational database records instead. Way more flexible.
• enitihas 6y ago
  What advantages does Mongo have over cloud managed NoSQL solutions lime cloud Firestore or aws dynamodb?
  • zachruss92 6y ago
    There are huge overlap between Mongo and Firestore. Mongo gives you the ability to finely control many aspects of the DB (sharing, replication, etc...) where as Firestore manages it for you. Firestore and DynamoDB are also closed source and you can only run them on their respective cloud providers. I don't have enough direct experience with DynamoDB to give you an accurate comparison.
• jiripospisil 6y ago
  Yes. We have applications running on both PostgreSQL and MongoDB and I find that working with MongoDB is just more pleasant. I think it mostly boils down to my preference of document databases as opposed to relational ones. It feels much more natural to me to embed / nest certain properties within a document instead of spreading it across several tables and then joining everything together to get the complete data. MongoDB makes working with these sometimes nested documents easy (I mean, it better) and there's always Aggregation Pipeline when you need it (something that I again find much more pleasant and readable over SQL). What always irks me is when somebody suggests PostgreSQL's json (or jsonb) types as an alternative to using MongoDB. All it's saying is that the person hasn't really invested a lot of time into MongoDB because there are things that PostgreSQL simply cannot do over a json type, especially when it comes to data updates. Or it can do that but the query is just overly complicated and often includes sub queries just to get the indexes into the arrays you want to update. All of that is simple in MongoDB, not really a surprise - that's exactly what it was made for. The last time I worked with PostreSQL's json I sometimes ended up just pulling the value out of the column entirely, modified it in memory and set the it back to the db because that was either way easier or the only way to do the operation I wanted (needless to say there are only exceptional cases where you can do that safely). Lastly, if you can easily replace MongoDB with PostgreSQL and its json types or you're missing joins a lot (MongoDB does have left join but it's rarely needed), chances are you haven't really designed your data in a "document" oriented way and there's no reason to use MongoDB in that case.
  • heipei 6y ago
    Yep, the update operators for MongoDB are really great and not replaceable with Postgres. Now if only MongoDB had a good sharding story it would be a worth contender for me.
    • takeda 6y ago
      As a person not familiar with mongo, what is it? From looking at the manual or looks like it's Mongo's equivalent of UPDATE statement.
  • scarface74 6y ago
• gitgud 6y ago
  I used it once, but now there's so many competitive alternatives. Firestore from Firebase is pretty similar and nice to work with, they also have a very generous free tier
• dreur 6y ago
  There is a very recent Jepsen report on MongoDB. http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6 > Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes and allow dirty reads, even downgrading requested safety levels at the database and collection level.
  • scarface74 6y ago
    Then don’t use the defaults? Sql Server use to have an empty password as a default for the Sa user and it was trivial to find servers exposed on the internet with the default password. While part of the blame was MS’s, it’s always on the person who does the installation to know what they are doing.
    • pritambaral 6y ago
      > Then don’t use the defaults? >> ... even at the strongest levels of read and write concern, it failed to ...
    • wlll 6y ago
      You should take a look at the Jepsen post. Kyle tested MongoDB at the highest integrity levels and still found problems.
  • LittlePeter 6y ago
    I don't understand half of what this means. Does it rule out MongoDB if you care about your data?
    • whalesalad 6y ago
      Yes.
    • jFriedensreich 6y ago
      yes, caring about your data and mongodb used to be even more opposites than now, but even with the improvements it's not a good fit.
• randtrain34 6y ago
  All of these replies are for Mongo's product 5+ years ago. MongoDB has changed A LOT since then. Has anyone used MongoDB IN THE PAST 2 YEARS?
  • romanovcode 6y ago
    Mongo is the PHP of databases. Just because it did change doesn't mean people want to use it.
  • lazersharkman 6y ago
    Why would you? The philosphy is the same even if you have better locking. It hasn't changed substantially. The only time you get schemas even are when you use it with like BI connectors. And that's just an accomodation.
  • kryptiskt 6y ago
    No, it's not open source anymore. Why use it when there are a multitude of fine and free databases available?
  • sbilstein 6y ago
    still lacks referential integrity and...i can't think of any primary store model that doesn't benefit from referential integrity.
  • ken 6y ago
    I think the saying goes: fool me once, shame on you; fool me for like 7 or 8 years in a row, shame on me. At this point, if MongoDB could turn on a dime from being an unreliable system to a robust one, that would be the most remarkable part of this story, because I've never seen that happen with any engineering organization. It's rare that engineering departments can significantly improve their quality culture, and it's never fast. Microsoft Windows went from crashing (for me) >=3 times a day to crashing almost never, and it took them over 10 years -- and replacing their kernel twice. I've seen nothing from MongoDB to make me believe they even realize the problem, much less are on their way to solving it. In the lifetime of a database, 2 years is nothing. And it's always easier for quality to slip than to improve. If they turned it all around since I last touched MongoDB, good for them, but they've burned through all their trust, and it's going to take a lot longer than that to earn it back.
• 013a 6y ago
  Yes. If we were going to start from scratch today, we'd probably use Postgres. But, realistically, the primary motivation behind that decision would be because Postgres is available on AWS, and that would centralize more of our operations. (DocumentDB is, of course available. Its not Mongo. I'd be curious to hear from people who actually had Mongo deployments and were able to move to DocumentDB; its missing so many of MongoDB's APIs that we physically can't, our applications would not run). Mongo isn't that bad. It has limitations. You work within the limitations... or you don't. But I really don't think a valid option is "mongodb fuckin sucks m8, shit tier db". We're not going to be migrating terabytes of data and tens of thousands of lines of code when the benefit is tenuous for our business domain. Should you use MongoDB today? I'll say No, but not for the reasons anyone else is giving. MongoDB's Cloud Provider agreement has decimated the cloud marketplace for the database. Essentially, if you want to run a version released in the past few years (4.2+), you need to be on their first-party Atlas product. Many other parties, especially the big clouds, are on 3.6 (or have compatibility products like DocumentDB/CosmosDB which target 3.6). Atlas is great. Its fairly priced and has a great UX and operations experience. But, I don't feel comfortable about there being political reasons why I couldn't change providers if that changes. If you have business requirements which demand, say, data in a specific region, or government-class infra, or specific compliance frameworks, Atlas may not be able to meet them.
  • mbell 6y ago
    > We're not going to be migrating terabytes of data You may have dramatically less 'real data' than mongo makes you think you do. I migrated one of our mid sized database out of mongo and into PG a couple years ago. The reduction in size was massive. One table in particular that was storing a small number of numeric fields per doc went from ~10GB to ~50MB. I wouldn't expect this with all datasets of course, but mongo's document + key storage overhead can be massive in some use cases.
    • damidekronik 6y ago
      Not OP but I think it's more about the importance of the said data, number of collections to think about and so on. Regarding your point, I would guess some index changes might have had a significant impact here.
• hartator 6y ago
  I am disappointed with the direction that MongoDB took this past few years. Going ACID shows in benchmarks [1] and it’s not advisable if you are using MongoDB for stats and queue. (No one uses MongoDB for financial transactions despite the changes.) And the recent change to a restrictive license is worrisome as well. I have been thinking of forking 3.4 and make it back to “true” open source and awesome performance. (If any C++ devs want to help out, reach out to me! username @gmail.com) [1] https://link.medium.com/PXIeZfhhH6 https://link.medium.com/PXIeZfhhH6
• UK-Al05 6y ago
  For those using postgres with jsonb, how easy it to scale postgres horizontally? We have used SQL databases in the past, and we've had to vertically scale them with incredibly expensive hardware.
• Buttons840 6y ago
  Does MongoDB still use multi-maps? That is, can a map still have multiple of the same key? This led to a very tricky bug at my last place of work, where the MongoDB Ruby client would see different values than the Python client. It's not a problem with MongoDB, per se, but many of the clients assume Mongo stores maps, when it really stores multi-maps. And it did hurt my opinion of the database seeing that most of its users we're not actually aware of the data structure it was based on. https://stackoverflow.com/a/35070928 https://stackoverflow.com/a/35070928
• alkonaut 6y ago
  Absolutely. Though by ”use” I mean maintain apps that wouldn’t be mongo today (and shouldn’t have been to begin with). Not worth migrating off it for small internal apps though.
• vivekkalyan 6y ago
  Anyone has thoughts about cassandra and how it compares to mongodb? There seems to be a big enterprise push with azure's cosmosdb, but I've not heard much about it from people who have actually used it.
  • rajman187 6y ago
    Unless you can hire Cassandra engineers who have enough experience maintaining clusters, or you can afford to pay DSE to do that for you, working with Cassandra will be quite the burden. The advancement of PostgrSQL has been amazing, and much credit is due indeed to the NoSQL community’s innovations. I cannot comment of MongoDB except to say that it is quite different than Cassandra. To summarize, be sure you really need Cassandra and are able to dedicate the appropriate resources to it before taking the plunge.
• tmjwid 6y ago
  Yes Our use case is dynamic dashboards generation where a document contains multiple components for our frontend to render. Having a simple unstructured database really helps us build the dashboard efficiently. Using a relational database would increase the development time of each dashboard tremendously and having relational integrity would make it even worse. Having a simple document with everything needed is a much nicer experience. Granted, our use case is very limited and it is read only.
• kevin_thibedeau 6y ago
  I had to port the BSON library to an embedded product. I wasn't pleased that their approach to malloc() failure is to call abort(). Fuck it, we're too lazy to report errors and degrade gracefully.
• flippyhead 6y ago
  Yes, and we really like MongoDB Atlas/Cloud
• codr7 6y ago
  I've promised myself to never touch MongoDB again. Worked for a valley startup back in 2013 that picked Mongo as primary data store because the CEO liked the simplicity and was too busy with the future to learn anything more complicated. I only implemented a couple of features before I got out of that mess. But from my experience, compared to dozens of SQL and NoSQL databases I've worked with; it was definitely the worst option. We spent way too much time dealing with Mongo-specific issues and limitations.
  • kgraves 6y ago
    That was like what, 7 years ago? Do you think this has changed now about Mongo since then?
    • kristaps 6y ago
      I had a similar experience around the same time - still don't feel like giving that widowmaker another chance.
    • codr7 6y ago
      The best predictor of future behavior is history. Much like the startup CEO I mentioned, Mongos developers don't really seem to care much about here and now.
  • bulldoa 6y ago
    Whats your opinion on postgres vs nosql like cassandra and aerospike, fundamentally is there any reason that postgres can't scale as well as nosql? If I store key value in postgres and add read replica to scale read and partition to scale write will I not be able to keep up with other nosql solutions? If so what are the reasons?
    • codr7 6y ago
      I would say that by the time you (potentially) have those kinds of problems, you'll most likely have the resources to deal with them. It's sort of a nice class of problems to have, and a lousy heuristic for choosing solutions before you know what exactly you're dealing with.
• k__ 6y ago
  Somehow I dodged that bullet. I only used RethinkDB and DynamoDB.
• 40four 6y ago
  I've actually never used it, and probably won't at this point. But, we do use Couchbase at my workplace, and it's worked well for us. The use case is very limited in scope, but it serves our purposes well. I'd be curious to know how they compare from folks who have used both?
  • trey-jones 6y ago
    I used CouchDB for a project back in 2012 when all of these things were fairly new. The reason was to embed the DB on an Android device. This turned out to not work as well as advertised. I have no idea what's happened with Couch since, but started got pretty familiar with Mongo in the last 12 months. It's OK, but it's expensive to make it performant. As other commenters here have mentioned, the primary use case for these Object/Document storage solutions seems to be to remove knowledge of Relational DB as a requirement for developers. I think it's probably excellent for prototyping, but I wouldn't want it running a heavily used product in production.
  • dynamite-ready 6y ago
    Depends on what you're doing, I suppose. CouchDB's multimaster concurrency features are still effectively best in class, but there are so many managed DB services now, that it doesn't seem like a headline feature. The RESTful interface is pretty cool. And Couch's in-built security features are near enough a best kept secret. CouchDB always lost to Mongo in discussions about speed unfortunately. Data safety and security notwithstanding. You can speed it up if you're willing to use Erlang as the primary query language, which wasn't something many were keen to do. Another big hamstring is data modelling in a document db... I'm not a data scientist, but anytime I hear complaints about Mongo, and have access to the codebase that's the subject of the complaint, I invariably find whopping great multi-property entities confined to a single document, without anything close to an attempt to normalise the data (or worse, a concerted intellectual effort to stuff everything into a single document...). There's more I can say... I think CouchDB is woefully underrated. It's on version 3 now...
    • rhythnic 6y ago
      Another CouchDB fan here. CouchDb's mango queries are implemented as Erlang map functions under the hood. Users now can get the speed of Erlang and the usability of Mongo-like query syntax.
• trey-jones 6y ago
  I got familiar with Mongo because of a piece of software that we acquired last year. It was way out of date and step one was to bring it up to latest. Step two was to change the hardware configuration and indexes to something reasonable. After doing this it's tolerable, but still lacking in speed per cost in my view. We have tentative plans to migrate to a relational database. There are probably good use cases for Mongo, but I haven't found one yet.
• cpburns2009 6y ago
  I only use it on one legacy website I maintain. It's used as a more advanced Redis to cache JSON structures and extract just the data that's needed. This use case has proved to be mostly useless. It would have been better to just use Redis which is already used for caching other data.
• arnejenssen 6y ago
  Yes. I've been using mongo for various projects for 8+ years. I like the flexibility of the document model. No migration headaches. The query language is powerful and intuitive. I haven't used the graph features yet, but it is nice to know that Mongo can support it if that need ever comes up. I use mongo Atlas as a managed database for peace of mind. I use Redis in addition for caching. For testing/TDD i use mongo-memory-database. It creates a isolated in-memory instance for each of my test suite, so there is no need for mocking.
  • wlll 6y ago
    How do you handle issues around data integrity? From http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6 > Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes and allow dirty reads, even downgrading requested safety levels at the database and collection level.
    • arnejenssen 6y ago
      Interesting. I haven't had a usecase where data integrity is critial yet. A project i'm working on now will have credits and accounts. To accomplish that in mongo. I create a transaction with with "pending" status. Then i try to debit the source account, and credit the destination account and I add the pending transaction to the accounts. If that works I set the transaction to "committed" and I remove the pending transactions from the accounts. https://gist.github.com/exoer/eee2aa37c86c06190f12ef4e2c6bd1c6 https://gist.github.com/exoer/eee2aa37c86c06190f12ef4e2c6bd1...
      • wlll 6y ago
        If you haven't already I would absolutely read the Jepsen articles on MongoDB, at least so you are aware of the risks and failure states. There's some stuff about transactions that may be relevant too.
• pavlov 6y ago
  Seems like nobody wants to use MongoDB, but at the same time it’s a $12B public company whose stock price is surging. Is MongoDB the new mini-Oracle?
  • quotha 6y ago
    That's what I am wondering, why is the stock so high? We used MongoDB maybe 6-7 years ago, and quickly moved on. Does it cost a lot to use?
  • omniscient_oce 6y ago
    There seems to be a hate bandwagon that everyone is jumping on; I've seen it on Reddit for about the last year or two. The one guy who talks about the issues with Atlas being the only platform which gets the latest versions does seem quite concerning though.
• Hackbyrd 6y ago
  No, MongoDB was a fad. Stick with relational databases like PostGreSQL (which in my opinion is the best and most straightforward)
• deleted 6y ago
  [deleted]
• bborud 6y ago
  No. It isn’t a good product and it encourages sloppiness that has to be cleaned up later.
• mbell 6y ago
  We have mostly moved off mongo at this point, there remains a single tiny mongo cluster running with a handful of collections that aren't worth the time investment to move at the moment. Almost everything moved to PG. The abstract issue we had with mongo is the purported 'best practices' with using it were seemingly in conflict with its actual implementation. I should note that these are issues across the last ~5 years so it's likely some of this has changed, it's also likely my recollection of the details are not perfect. Mongo pushes the idea of keeping related data in a single document. So if you have a hierarchy of data, keep in all in a nested document under a 'parent' concept, say an 'Account'. The problem with this is that there is a document limit of 16MB and key overhead is high. At one point we had to write a sharding strategy where by data would be sharded across multiple documents due to this limit. This also broke atomic updates so we had to code around that. We also ran into a problem where for some update patterns, mongo would read the entire document, modify it, then flush the entire document back to disk. For large documents, this became extremely slow. At one point this required an emergency migration of a database to TokuMX which has a fast update optimization that avoids this read-modify-write pattern in many cases, as I recall it was something like 25x faster in our particular situation. This same issue caused massive operations issues any time mongo failed over as the ram state of the secondary isn't kept up to date with the master so updates to large docs would result in massive latency spikes until the secondary could get it's ram state in order. In general we just found that mongo's recommended pattern of usage just didn't scale well at all, which is in contrast to its marketing pitch. I think at one point we had something around 6TB of data spread across 3 mongo clusters. After migrating most of that to PG or other stores and reworking various processes that could now use SQL transactions and views, the data size is a small fraction of what it was in mongo and everything is substantially faster. In one extreme example there was a process that synced data to an external store as the result certain updates. Because we couldn't use single documents and had no cross document update guarantees we would have to walk almost the entire dataset for this update to guarantee consistency. It got to the point that this process took over 24 hours and we would schedule these update to run over a weekend as a result. With the data moved PG, that same process is now implemented as a materialized view that takes ~20 seconds to build and we sync every 15 minutes just to be sure. Granted this improvement isn't just a database change but rather an architectural change, however mongo's lack of multi-doc transactions and document size limit are what drove the architectural design in the first place. Then there are bugs, of which there were many, but the worst of which was a situation where updates claimed to succeed, but actually just dropped the data on the floor. I found a matching issue in mongo's bug tracker that had been open for years at that point. Ultimately I just can't trust a datastore that has open data loss bugs for years, regardless of its current state.
• lcfcjs2 6y ago
  I love MongoDB, but recently I have been favoring CouchDB for my projects, its a quick and easy setup.
• daneel_w 6y ago
  I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, that software is often shaky in its infancy but almost always improves over time.
  • throwawaygh 6y ago
    I had to rip out a comletely schemaless mongodb and replace it with a sql DB. The data was completely relational, and developing without a schema was a pita. I asked why mongodb was used in the first place. As far as I could tell, the answer was one resume driven dev. If a document store made sense for our data then we would’ve made mongodb work. It was less “we got burned” and more “why were we using mongo in the first place?”
    • daneel_w 6y ago
      This was a bit of a hidden point with my comment. A poor choice of tool for the job is a completely different problem than the tool being poor.
  • derivagral 6y ago
    I don't think this is limited to devs or databases. You see it sometimes in Firefox/Chrome threads along the lines of "firefox sucks", "when did you last use it?", "4 years ago". Mongo in particular had marketing plays that were quite deceitful; that particular flavor of distate can run deeper than some tech issues. disclaimer: I use mongo in my day to day as a primary DB store.
  • AdrianB1 6y ago
    If you have a problem with product A and you have 10 other options, find product B is good enough and start working with it, there is no need to go back to A from time to time to see if it was improved. And watching all the 10 products like a horse race and move to the best of the hour is not reality.
• workingname 6y ago
  We've used it for several years after switching away from it for Docdb last year and then back again in November. We've had applications running on both MongoDB and AWS continuously through 2019, but our clients and team in general needed certain things: Ddb doesn't support everything we've done w/ mongo in the past. Our team also feel it's easier to integrate and translate to clients.
• deleted 6y ago
  [deleted]
• softwarerero 6y ago
  Definitely, for most projects. Also the combination of Meteor and MongoDB allows for great development speed.
• code4tee 6y ago
  There are some legacy things in place for now, but not building anything new there now. It’s basically off the table for new builds.
• samgranieri 6y ago
  Maybe in an errbit installation if I don't feel like using a postgres fork. Honestly, I get everything I need out of a JSONB field in postgres, so no, not for greenfield projects
• crankylinuxuser 6y ago
  Yep. Thats only because Graylog requires it. We don't put any real data in Mongo. That'd just be silly. I'd put SNMP telemetry data in Mongo, only for the fact that recording that can be somewhat lossy. Plainly, I just don't trust Mongo with consistency, availability, or partition tolerance. And because Mongo's backup facilities suck (requires taking the DB into readonly, or accepting no time consistency egads), the only good way to do a backup is to put the DB on LVM, and making a LVM snapshot.
• marshmellman 6y ago
  Has anyone successfully migrated from MongoDB to a relational database like Postgres? My team used Mongo, but we have a classic relational use case. We’re being bit by application code joins, no cascade delete, sloppy schema changes.
• stetrain 6y ago
  I'd be curious if anyone has experience using Mongo or other document DBs as a read model projection database in a CQRS event sourced system. That is, data which can be reconstructed from a consistent event store at any point, and is organized into structures for fast querying and loading for display on the client. - Backend load -> update -> store updates must be atomic and consistent - Client reads are fine being eventually consistent - Need to store structured data (ie a calendar event with the names of all participants) but also find and update nested data (ie a participant's name changes). - Client queries need indexed filter and sort capability on specific document fields. Mongo or similar databases seem like they might be ideal for this use case, since they allow storage of nested document data while still being able to index and perform updates on that nested data, but I haven't really seen a deep dive from anyone using it for this purpose.
• ecoqba11 6y ago
  Yes, but migrating to PostgreSQL.
• CyanLite2 6y ago
  We stopped using it because indexing was annoying, and we found a product (CosmosDB) that automatically indexes everything for us and still has a pretty decent SQL-like query syntax. I also think the "cool" factor has stopped. It was very chic to use Mongo back in 2010 when everybody else was trying to scale with SQL. Nowadays, DynamoDB/CosmosDB/Cassandra eats Mongo for lunch.
• chooseaname 6y ago
  Looking at the responses, I'm seeing a fair number of "No" responses. I recall a time when devs would practically rage on you if you dared question the decision to use Mongo. What changed? Is it just an example of dev cultism where the cult devs are the loudest?
• collyw 6y ago
  Sadly my work is on Mongo.
• pictur 6y ago
  Mongodb can make your simple problems more complicated and you may notice this too late
• SergeAx 6y ago
  Yes, we are using it at iFunny (20М+ installs on iOS + Android). 180 virtual servers in 12 clusters. Reasons are scalability and reliability. We can turn off any baremetal host under those virtual servers and system won't even notice that (it actually happens 2-3 times a year). We can add/remove replicas to scale reading load and add/remove shards to scale writes.
• RyanGoosling 6y ago
  MongoDB is for devs who don't respect data
• mroche 6y ago
  I’m in the process of learning some database work and an inventory project we have is using Mongo as its store. Has anyone looked at or used ArangoDB as a NoSQL solution? It seems pretty decent at first glance with some interesting flexibility. https://arangodb.com/ https://arangodb.com/ https://github.com/arangodb/arangodb https://github.com/arangodb/arangodb
• varbhat 6y ago
  NO. PostgreSQL is recommended but it depends on your usecase.
• swah 6y ago
  I have to say https://www.mongodb.com/cloud/atlas https://www.mongodb.com/cloud/atlas is awesome. Use it at work and would like to use it on personal projects in the future instead of whatever other DB solution.
• XCSme 6y ago
  The company went bakrupt, but the game we made[0] still lives. It uses MongoDB to store user accounts, profiles, inventories, match history and all persistent data. I was the one who suggested to use MongoDB when we started (instead of SQL) as the game front-end was JS and back-end Node.js, meaning that having a MongoDB database we could easily type, store and retrieve data. Overall I think it was a good decision, it ran pretty well with over 200k MAU, ~2-3k concurrent. We never really had performance issues with the database, but we did have to implement our own locking system to make sure that non-atomic operations are performed correctly. I think there are only 3 VPSs running MongoDB (one master, one replica and one back-up I think), so actually the entire database (a few gigabytes with around 1M accounts) only runs on a single cheap VPS. [0]: https://curvefever.pro https://curvefever.pro
• fag_rape 6y ago
  JavaScript is shitty, and JSON is even shittier. Fuck all this trash. I hate all computers, but I hate JavaScript and everything related to it EVEN MORE.
• d3ntb3ev1l 6y ago
  I had some positive outcomes using Postgres and Mongo as essentially a front end cache. The use case was unique in that all of the spark/etl jobs ran against postgres, which then triggered caching workers to build up a more document oriented cache that the front end talked to. Essentially allowing the front end to get a KV on steroids and documents already prepared well to be rendered and pre joined. Against a specific use case. I was never burned by Mongo, but I wouldn’t choose it if I had to have one backend only. It lends itself nicely as part of an ecosystem imho
• mememem 6y ago
  Yes, for prototypes, MVPs, temporary chaotic storages. NO MongoDB for production workloads. No MongoDB for more than 1000 records in one collection. No MongoDB higher 4.0.3.
• hootbootscoot 6y ago
  I was very happy with Scalegrid hosted MongoDB for the 2 years a project ran on it. Prior to that, 1 year on a self-hosted cluster had a failed write due to a network partition and I learned about single write masters and used CouchDB on my next "document-DB-appropriate" project. Atlas ended up being expensive and the service was a bit stand-offish, where Scalegrid's staff were super helpful etc... Their pricing was the primary factor. What do I define as "document-DB-appropriate"? Blobbed stuff where you want it all in the same document sized doses, and always the same dose, to the point where you feel ridiculous putting bits together in the same shape over and over and notice that you CRUD the same dose/shape all day... Objects... Don't get me wrong, there's times in computer data land when the first 128 bytes are the header and that the data is multiplexed in 32bit chunks with 24 bits zero-padded and this padding tells you "channel 2 is starting now buddy!" But SQL is certainly a viable option for many things and rather standard and known and supported and stuff...
• deleted 6y ago
  [deleted]
• horizontech-dev 6y ago
  On a side note, I always wonder how their valuation ($MDB) keeps getting increased!
• rmdashrfstar 6y ago
  The main argument for using MongoDB when you’re abiding by DDD: https://martinfowler.com/bliki/AggregateOrientedDatabase.html https://martinfowler.com/bliki/AggregateOrientedDatabase.htm...