Do you still use MongoDB?

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.

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.

There is a very recent Jepsen report on MongoDB. 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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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?

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...

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.

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.

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.

No - Postgres is faster and it has JSONB. (It also has tables and SQL and GIS and ...)

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

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

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.

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.

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.

Mongodb can make your simple problems more complicated and you may notice this too late

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.

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

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.

I have to say 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.

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?

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?

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

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.

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://github.com/arangodb/arangodb

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.

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

yes. Because we scrape data from different websites, and they each has very a different content format. mongodb handles unstructured data well

No, MongoDB was a fad. Stick with relational databases like PostGreSQL (which in my opinion is the best and most straightforward)

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.

Definitely, for most projects. Also the combination of Meteor and MongoDB allows for great development speed.

The main argument for using MongoDB when you’re abiding by DDD: https://martinfowler.com/bliki/AggregateOrientedDatabase.htm...

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?

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.

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.

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.

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

NO. PostgreSQL is recommended but it depends on your usecase.

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.

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.

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.

What advantages does Mongo have over cloud managed NoSQL solutions lime cloud Firestore or aws dynamodb?

I've heard it's webscale! ;)

No. It isn’t a good product and it encourages sloppiness that has to be cleaned up later.

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.

On a side note, I always wonder how their valuation ($MDB) keeps getting increased!

I use it for small personal stuff because it’s easy for me to play with

How are you guys monitoring mongodb instances in Google Cloud?

Yes, and we really like MongoDB Atlas/Cloud

Somehow I dodged that bullet.

I only used RethinkDB and DynamoDB.

Yes, but migrating to PostgreSQL.

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.

Sadly my work is on Mongo.

MongoDB is for devs who don't respect data

I never used it and don't plan to.

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.