
Ask HN: Do you still use MongoDB? - macando
Haven&#x27;t heard anything about it in a while. Do you still use it or stopped using it. Why?
======
josephg
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
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
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.

~~~
danenania
DynamoDB is a lot more explicit about its tradeoffs. Much of the backlash
against Mongo was because it basically claimed to be well-suited to _any_ use
case, when its sweet spot was really far narrower. To be successful with
Mongo, you need to design the entire app around its limitations, but those
limitations were initially downplayed and obscured.

People were convinced that Mongo was a good choice as a default, general
purpose db, when it clearly wasn’t for about a million reasons.

I don’t think DynamoDB is marketed or viewed in the same way. The docs are
pretty clear about needing to design your data model to specifically work well
with Dynamo. People using it seem to generally be aware of its limitations,
and deliberately choose to accept them for the sake of performance and
scalability. At least that’s my perception.

~~~
hartror
What are those good use-cases for mongo?

~~~
danenania
Basically when speed and horizontal scalability are very important, and
consistency/durability are less important. It’s also pretty good for
unstructured or irregularly structured data that’s hard to write a schema for.

Web scraping or data ingestion from apis might be a reasonable use case. Or
maybe consumer apps/games where occasional data loss or inconsistency isn’t a
big deal.

It can also be used effectively as a kind of durable cache (with a nice query
language) in place of redis/memcached if you give it plenty of ram. While its
guarantees or lack thereof aren’t great for a database, they’re pretty good
for a cache.

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

~~~
thomascgalvin
This is (probably) an artifact of Mongo's schema-less nature; when you don't
have tables with structure, every document you store has to detail its own
schema inline.

In a relational database, you have columns with names and types, and that info
is shared by all of the rows.

In Mongo, every cell has to specify its name and type, even if that layout is
shared by every other cell in the document.

Mongo's way is more flexible, but it's terrible for storage efficiency.

~~~
rubyfan
/caveat i know nothing about how mongo is storing data and haven’t used it
since 2010

it doesn’t really have to approach the schemas that way. one would think it
would be optimized for repeat schema in the same way one might create the
schema definition and then reference it in packing and unpacking the data.
seems like if there was schema overhead taking up storage unnecessarily that
could be optimized relatively easily.

having schema references also might be a good management tool to understand
which records vary potentially due to an application evolving it’s needs.

~~~
carlps
There's something beautiful about normalizing the storage of denormalized
schemas.

~~~
jgalt212
Yes, and the sooner you do it the better. But doing it during project planning
/ experimentation phase (or when you don't know what the final result should
be yet) will really just slow you down. In many ways, very similar to the
static / dynamic language trade offs.

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

~~~
LittlePeter
I don't understand half of what this means. Does it rule out MongoDB if you
care about your data?

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

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

~~~
asah
I'm curious, any chance you remember some of those json/jsonb update hassles?

(not arguing, just curious - when things get hairy in JSON, I give up on SQL
and [1] I write a user defined function (CREATE FUNCTION) in JS (plv8) or
Python (plpython).

[1] assuming the update code needs to run inside the database, e.g. for
performance reasons... otherwise just perform your update in the application,
where you presumably have a richer library for manipulating data structures...

~~~
jiripospisil
I don't remember the specific case (it's been a few years) but I do remember
it had something to do with updating an array member. I googled around and
found this [0] (the second question) which looks very similar. It's as simple
as it gets - find an array member with "value" equal to "blue" and decrease
its "qty". In MongoDB you can do that pretty easily ([1]) and the update
should be atomic. The SQL version looks complicated and it's not even the form
that you should use (notice the note about the race condition). Then again,
maybe there's already a way to do that in PostgreSQL in a more elegant way, I
assume the support has improved over the years.

[0] [https://dba.stackexchange.com/questions/193390/update-nth-
el...](https://dba.stackexchange.com/questions/193390/update-nth-element-of-
array-using-a-where-clause)

[1]
[https://gist.github.com/jiripospisil/36f37a41f9b2c7fe74e841e...](https://gist.github.com/jiripospisil/36f37a41f9b2c7fe74e841eb064be9d7)

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

~~~
gavinray
> "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."

Ahh yes, just like the dialogue of the never-stale "Mongodb is Webscale" meme
video:

[https://www.youtube.com/watch?v=b2F-DItXtZs](https://www.youtube.com/watch?v=b2F-DItXtZs)

[http://www.mongodb-is-web-scale.com/](http://www.mongodb-is-web-scale.com/)

> _MySQL is slow as a dog. MongoDB will run circles around MySQL because
> MongoDB is web scale._

> _" MongoDB does have some impressive benchmarks, but they do some
> interesting things to get those numbers. For example, when you write to
> MongoDB, you don't actually write anything. You stage your data to be
> written at a later time. If there's a problem writing your data, you're
> fucked. Does that sound like a good design to you?"_

> _If that 's what they need to do to get those kickass benchmarks, then it's
> a great design._

> _"..... If you were stupid enough to totally ignore durability just to get
> benchmarks, I suggest you pipe your data to /dev/null. It will be very
> fast."_

> _If /dev/null is fast and web scale I will use it. Is it web scale?_

> _" You are kidding me, right? I was making a joke. I mean, if you're happy
> writing to a database that doesn't give you any idea that your data is
> actually written just because you want high performance numbers, why not
> write to /dev/null? It's fast as hell."_

> _Does /dev/null support sharding?_

~~~
lgl
Those videos (that being the most infamous) will never stop being hilarious.
The node.js one is also pretty amazing:

[https://www.youtube.com/watch?v=bzkRVzciAZg](https://www.youtube.com/watch?v=bzkRVzciAZg)

------
niffydroid
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
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
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
This is a great testimonial. Would you care to share what Atlas is/which
software package Atlas is?

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

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

~~~
tjalfi
Life is too short to reevaluate every technology I've had a bad experience
with.

You only get one chance to make a first impression - I'll probably stick with
it unless I get an excellent reason to change my mind.

How often do you reevaluate technologies that you've had a bad experience
with?

~~~
daneel_w
How often I re-evaluate applications, you mean? I would say it happens
somewhat regularly; if there's something I miss with one I switched from, or
if I hear or read something good about an application I stopped using.

~~~
contrast
I guess the more interesting questions are how often you re-implement
discarded technologies back in to your core stack after they’ve let you down,
and how much time you spend re-evaluating your core tech but don’t find enough
improvements to incur the switching costs.

For something as fundamental as the database, most developers (and people who
rely on them) would probably hope for “rarely” and “not much”. What are the
benefits you see from taking a different approach?

------
codr7
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
That was like what, 7 years ago? Do you think this has changed now about Mongo
since then?

~~~
kristaps
I had a similar experience around the same time - still don't feel like giving
that widowmaker another chance.

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

------
arnejenssen
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
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
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/eee2aa37c86c06190f12ef4e2c6bd1...](https://gist.github.com/exoer/eee2aa37c86c06190f12ef4e2c6bd1c6)

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

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

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

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

------
adityapatadia
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
What is your business/website ?

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

------
heipei
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
Atlas makes sharding easier, it's just one button where you define your
partition key.

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

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

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

------
randtrain34
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 __?

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

~~~
ncmncm
I worked there. They realize the problem, and are smart enough to fix it.

Their problem is that the customer base they have doesn't want the solution.

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

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

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

------
pavlov
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?

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

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

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

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

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

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

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

------
hartator
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)

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

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

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

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

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

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

------
XCSme
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)

------
jondubois
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
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/)

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

~~~
qatanah
Exactly it's a bit more of work does make you prone to mistakes. This is what
happens when you rewrite transaction on your application. See what happens
with to a btc exchange using mongo who got hacked.

[https://dzone.com/articles/mongodb-bitcoin-how-
nosql](https://dzone.com/articles/mongodb-bitcoin-how-nosql) (article is 2014)

I'm a bit outdated with mongo since 2.4-2.6 . It's a bit traumatic and i'm
never coming back to it.

If in case I'll need a high atomicity and consistency for financial
transaction i'll just use postgres with SERIALIZABLE transaction isolation.
This solves everything.

Checkout the redbook.io it's a bit outdated but you can see from
stonebreaker's discussion that nosql + sql will merge, which is what happening
or happened right now. Mongo having transaction, and SQL having json
datatypes.

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

------
chooseaname
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?

------
40four
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?

~~~
dynamite-ready
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
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.

~~~
40four
Thanks for the CouchDB feedback guys! I am curious to try it out. I should
have been more clear, I was actually referring to Couch _base_
([https://www.couchbase.com/](https://www.couchbase.com/)) not CouchDB :) Very
unfortunate naming conflict considering they are both JSON document stores. Is
there something about the word 'couch' that I'm missing?

From my experience with Couchbase though, I would recommend it to others. They
support SDKs in many languages, have decent documentation, and the server has
performed well for us. The query language 'N1QL', tries to emulate SQL syntax,
and I found it nice to work with.

~~~
dynamite-ready
Couchbase was a commercial CouchDB spinoff product, co-created by the
programmer who created CouchDB. Much of the API is (was?) the same, but where
possible, Erlang was exchanged for C++.

It also has a built-in, in-memory cache layer, which CouchDB doesn't have.

~~~
40four
Oh wow, thanks. I didn’t know the history of it!

------
Buttons840
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)

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

------
mroche
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)

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

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

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

~~~
TomMarius
Have you compared with postgresql's jsonb?

~~~
Beefin
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
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
[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
If a man is surrounded by trees, does he become a grove?

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

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

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

------
rmdashrfstar
The main argument for using MongoDB when you’re abiding by DDD:
[https://martinfowler.com/bliki/AggregateOrientedDatabase.htm...](https://martinfowler.com/bliki/AggregateOrientedDatabase.html)

------
franciscop
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?

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

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

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

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

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

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

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

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

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

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

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

------
ochronus
I've heard it's webscale! ;)

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

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

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

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

------
econcon
How are you guys monitoring mongodb instances in Google Cloud?

------
flippyhead
Yes, and we really like MongoDB Atlas/Cloud

------
k__
Somehow I dodged that bullet.

I only used RethinkDB and DynamoDB.

------
ecoqba11
Yes, but migrating to PostgreSQL.

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

------
collyw
Sadly my work is on Mongo.

------
RyanGoosling
MongoDB is for devs who don't respect data

------
pjmlp
I never used it and don't plan to.

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

