
MongoDB History - jaysonqpt
https://www.quickprogrammingtips.com/mongodb/mongodb-history.html
======
chrisfosterelli
MongoDB still has an awful reputation on Hacker News but I really appreciate
the take from "Why RethinkDB Failed" [0]:

> People wanted RethinkDB to be fast on workloads they actually tried, rather
> than “real world” workloads we suggested. For example, they’d write quick
> scripts to measure how long it takes to insert ten thousand documents
> without ever reading them back. MongoDB mastered these workloads
> brilliantly, while we fought the losing battle of educating the market.

> almost everyone was asking “how is RethinkDB different from MongoDB?” We
> worked hard to explain why correctness, simplicity, and consistency are
> important, but ultimately these weren’t the metrics of goodness that
> mattered to most users.

> But over time I learned to appreciate the wisdom of the crowds. MongoDB
> turned regular developers into heroes when people needed it, not years after
> the fact. It made data storage fast, and let people ship products quickly.
> And over time, MongoDB grew up. One by one, they fixed the issues with the
> architecture, and now it is an excellent product. It may not be as beautiful
> as we would have wanted, but it does the job, and it does it well.

In my mind Mongo is a database that had great developer experience, excellent
marketing, and some seriously bad technical gotchas. But marketing drove
momentum long enough to cover bills, grab the market, and address most of the
gotchas, so now it's a decent DB.

[0]: [https://www.defmacro.org/2017/01/18/why-rethinkdb-
failed.htm...](https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html)

~~~
jaysonqpt
I think MongoDB 3.6 is when it became a "decent" DB.

Azure CosmosDB provides protocol level for MongoDB 3.6. This offers developers
a neat way of using the power of distributed CosmosDB without sacrificing
cloud portability.

~~~
stennie
Cosmos' API is an emulation of MongoDB which differs in features,
compatibility, and implementation from an actual MongoDB deployment. Cosmos'
suggestion of API version support (eg 3.6) is referring to the MongoDB wire
protocol rather than the full MongoDB server feature set for that version.
There are also some inherent differences, such as Cosmos' Request Units (RUs)
which need to be considered for capacity planning and costs:
[https://docs.microsoft.com/en-us/azure/cosmos-db/request-
uni...](https://docs.microsoft.com/en-us/azure/cosmos-db/request-units).

Those differences may be fine for some use cases, but definitely compromise
portability if you want to run or test the same application with a database
deployment on GCP, AWS, or your own infrastructure. The lowest common
denominator is based on Cosmos DB's underlying limits and features (not a
MongoDB server feature set): [https://docs.microsoft.com/en-us/azure/cosmos-
db/concepts-li...](https://docs.microsoft.com/en-us/azure/cosmos-db/concepts-
limits).

------
slyall
The "Mongo DB is Web Scale" video just turned 10 years old. I'm pretty sure
that was a big factor in MongoDB not being taken seriously by many people.

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

~~~
threeseed
Anybody who makes complex technology decisions based on marketing copy doesn't
deserve to be taken seriously either. Not that I think these people actually
exist other than in the minds of many HN commenters.

Oracle on their website right now says "we lead the market in autonomous,
cloud, and applications technologies".

I assume you think developers are going to suddenly abandon AWS, Python etc
and move entirely to an Oracle stack based off this quote ?

~~~
blibble
at large firms the clueless technology managment often buy based on the
marketing crap, then force it down the throats of the engineers

at my firm we're being all but forced to use Azure even though it costs more
and makes absolutely no sense whatsoever for the domain, but since it's the
"technology strategy" fighting it becomes exceptionally difficult

~~~
jd_mongodb
In seven years working at MongoDB the one thing I have learned is technology
is never "forced down the throat of the engineers". Developers have choices
and would not stay in an organisation that made decisions that way. The reason
developer relations exists is the acknowledgement that developers ARE the
decision makers in most technology selection.

~~~
NegativeLatency
I recently worked for a company where a different popular JSON document
database was in fact forced down my throat.

I proved that a regular database would be orders of magnitude faster with a
real example on real data and while the project/product was canceled for
marketing/sales reasons. Until it was canceled we were told by multiple levels
of "technical" managers to use the worse database because of unknown reasons.

~~~
jd_mongodb
Technology selection is a black art in many companies. Sounds like people were
open to listening to the opinion of a developer in your case. Often-times the
selection heuristic is habit or history. The right companies will pay more
attention to reasoned arguments of their own developers.

~~~
NegativeLatency
The wild part about it was that they were trying to use elastic search for
relational queries because some manager thought it would be faster than a
relational db. (It was about 60x slower)

------
mattbillenstein
Mongo is much maligned here and I hesitate to even comment for fear of attack,
but in my mind it has some compelling use cases and after Wired Tiger became
the default storage engine, that pretty much solved the issues with compaction
I had seen in the past while delivering a lot more performance.

I've built systems with it where we didn't own the schema - we were scraping
data from other places and schemaless was a feature. And I benchmarked it
against Postgres and a couple other things and I just couldn't get the same
performance - note our operations were idempotent to the db, so even in a hard
crash, we could just re-run the scraping job and we wouldn't really "lose" any
data -- or even if the data was stale by a day, not a big deal... That system
would do tens of millions of upserts per night on not crazy AWS hardware and
it ran for years like this without problems.

Would I use mongo for situations where I needed transactions? Almost never - I
actually like Postgres a lot and it's my default for your run of the mill CRUD
apps since you can do geo, crypto, search, etc by just installing a few
extensions. Do I got on HN on every mongo article and bash them constantly?
No, I think they've built a pretty decent thing if you understand the
implications of not confirming writes to replicas and whatnot and tune it to
your needs.

------
skywhopper
Lots of interesting info, and I really like working with MongoDB. But I am
baffled by the claim that "MongoDB is the king." In all the circles I work in,
I only hear Mongo dismissed as a joke. Unfortunately the company's
dismissiveness of RDBMSes, their hubris in pushing NoSQL, and their blunders
over what are extremely poor default settings all combine to make MongoDB
something I don't see anyone taking seriously. I use it in a project where
it's basically just serving as a big cache, so the reliability and durability
of the data is not critical. It's certainly way easier to query than any other
document-oriented database, but getting a foothold to use for anything
requiring long-term storage would be a major challenge.

~~~
conradfr
I interviewed recently at a payment provider that is rewriting its PHP/Mysql
monolith in Java & go microservices with MongoDb.

The architect would praise static typing but would prefer MongoDb "because
it's easier to add a column". It felt weird but I've never used MongoDb so I
could not really argue about it.

~~~
manigandham
Sounds like a bad architect or someone who only knows surface features and
doesn't have experience with the actual databases.

Adding a column is not hard in any relational database, and pretty much all
modern ones support no-downtime transactional schema updates with backfills,
concurrent index builds, etc.

Also the schema always exists somewhere, and it's usually to put it in the
database so it's next to (and validates) your data rather than keeping spread
out in your application code.

~~~
threeseed
Database schemas only validate the data type and whether it's null or not.

It's next to useless for ensuring data integrity and why every app you see
will have data validation inside the code itself. Whether it's checking that
an email has a valid structure or that a payment is not negative.

Majority of the logic will be the code so it makes no sense to me other than
if you have multiple clients accessing that database why it must be enforced
at the database level as well.

~~~
RedShift1
The examples you give are perfectly possible in any decent SQL server (mssql,
postgres). If anything, database servers are made to ensure data consistency,
checks like "payment not negative" are no brainers. If you don't define these
constraints at the database level you are leaving its power on the table and
are re-inventing the wheel by putting it in your application layer somewhere.

------
tobyhede
A complete history with all the data ... unlike MongoDB. Boom tish etc.

~~~
numlock86
I never got a definite answer: What problem does MongoDB even try to solve?

~~~
threeseed
MongoDB is the fastest and easiest to scale schema-on-read document store.

So if your domain model is document orientated e.g. a star schema with dozens
of joins, where you don't know the schema upfront or you have polymorphic
relationships it is a really useful way to store your data.

~~~
numlock86
Hm, my impression was always that if I have such data I didn't really
understand my data yet. What's a concrete prime example for using MongoDB?

~~~
staysaasy
That's actually kind of the point – if you're working on a new project whose
requirements might change rapidly Mongo can be a really great fit (eg a toy
project; a prototype for a new internal service; a hackathon; a pre-traction
startup).

------
jd_mongodb
A pretty solid history. Kinda skipped over the launch of MongoDB Atlas, but
this is the only miss in a pretty accurate account.

------
surajs
Hugh mongo... Sorry wrong website

------
jaysonqpt
A detailed and interesting history of MongoDB database.

