
Startup Engineers and Our Mistakes with MongoDB - nemild
https://www.nemil.com/mongo/2.html
======
slap_shot
It terrifies me to see this quote from their CTO:

"MongoDB's CTO disagrees with this statement arguing that nearly 90% of
database installations today would benefit from being replaced with MongoDB."

I used to attend "office hours" at MongoDB's office where guests ask MongoDB
employees for help. Most of my questions involved very complex aggregation
queries (that would have been trivial in SQL) that even MongoDB employees
could not solve.

While I waited to be helped I would listen to other people ask the same
questions over and over and over: "How do I join these two collections? How
can I <perform a transaction> and ensure both writes succeed/fail?"

Rather than say "MongoDB doesn't offer this functionality" and maybe advise
them that this database isn't what they needed for the specific project, the
engineers spent a majority of these office hours explaining they don't need
schemas, transactions, relations and advised them how to hack together
something that worked.

I don't think MongoDB is appropriate for 90% of the database installations out
there. I don't know the number, but it isn't 90%, it isn't a majority, and
doubt it's a significant number.

MongoDB really needs to explain what it does exceedingly well versus the other
distinct offerings in databases (RDBMS, Key Value stores, MPP/warehouses,
HDFS, etc) and market that.

What they do right now is somewhere between disingenuous and down right
negligent.

Of course its the responsibility of a company and its staff to choose the
right tool for the job, but these postmortems are becoming tiring.

~~~
threeseed
I really don't understand your comments.

You're critical that MongoDB employees whose job it is to help people use the
product showed users approaches to implement their use cases. How is that bad
or somehow unique ? I've been to Datastax, MySQL, Oracle, Teradata, Cloudera,
Hortonworks workshops before and all of them did the same thing. It's their
job.

Also MongoDB has been crystal clear what it offers in comparison to other
databases. It is a document database with easy to use scalability options in a
market that doesn't have many of these. And it's mentioned throughout their
documentation and by third parties about the pros/cons of document databases
and how to appropriately model your data.

And yes these postmortems are becoming very tiring. Engineers should not be
pushing any technology without a spike to determine whether it's appropriate
or not. If you don't have a document orientated data model then don't use a
document store.

~~~
pritambaral
> approaches to implement their use cases.

This is where you and your parent disagree. Your parent believes they showed
"hacks" and not "approaches to implement their use cases".

------
MikeKusold
> By far the most consistent mistake was choosing a non-relational database,
> when your data was strongly relational. Mongoose's ODM made this mistake
> surprisingly easy to make, which led to issues down the line.

This mirrors my experiences with Mongo as well. The vast majority of data is
relational. Mongoose allows people to make the mistake of structuring their
data relationally. But all you are doing is pushing all the joins to the web
server (which in Node land is single threaded and compounds the mistake of
choosing NoSQL).

There may be some microservices that Mongo is great fit for, but it should not
be your core data store.

~~~
mrtksn
If data needs to be processed, an option would be to use MongoDB for
collecting the data in bulk and later decide how you need to structure it for
your needs.

When it comes to "read" the data, you read it only from processed database
that can be anything.

Since you can do your processing completely independently of your web server,
your are not necessarily pushing your computational load from the DB to the
web server.

~~~
flavio81
> If data needs to be processed, an option would be to use MongoDB for
> collecting the data in bulk and later decide how you need to structure it
> for your needs.

OR, i can open a file stream, serialize my data to JSON, entity by entity, and
dump all to a file.

The good old file.

~~~
threeseed
Because we want to do partial updates, searches, indexing etc.

Your position can be applied to all databases. Why not abandon them all and
just use CSV ?

~~~
bdcravens
You could always do that, dump the data to s3, and use Athena :-)

[https://aws.amazon.com/athena/](https://aws.amazon.com/athena/)

~~~
pritambaral
And then be locked-in to Amazon. From ubiquitous files to ... a single service
provider.

------
pryelluw
I feel the best thing to come out of MongoDB is that Postgres now handles
JSON.

~~~
STRML
Yes, this was an incredible development, and lead to hilarious projects like
ToroDB (MongoDB API on top of Postgres), which ended up being faster and
safer, with relations when you need them.

JSON columns can be incredibly useful and easy to understand for things like
user preferences, without the hassle of a metatable.

~~~
tinix
Call this hilarious if you want, I think it's rather cool, thanks for the
pointer. Once this is out of beta it will definitely be useful, if not
already.

------
adjkant
The reality of MongoDB is that it's a very specific use case of nonrelational
data, which is very rare these days. I'm sad that so many people get looped
into Mongo with a MEAN/MERN stack when those apps are almost always the CRUD
apps that would benefit from SQL. Why force yourself to maintain a schema
implicitly for relational data when you can get error messaging and explicit
schemas?

I think MongoDB is a great fit for the right problem. I've been coding for 4
years and have yet to find a problem that fit Mongo best.

As far as quick prototyping goes, this article articulates well why that
really isn't the case. Going back to the authors post here on HN, that's a
point I would really disagree with the CTO on as well.

~~~
scarface74
"I've been coding for _4 years_ and have yet to find a problem that fit Mongo
best."

I'm going to leave that right there.....

~~~
adjkant
I can't read the implication of this, but to clarify, I haven't personally
encountered a problem that fit Mongo best. I can imagine one.

------
flavio81
Today in 2017, there is no real reason to use MongoDB other than in
prototyping. I am happily waiting until the final nail is put on the coffin of
this overhyped, flawed document store.

~~~
optimuspaul
"Today in 2017, there is no real reason to use Oracle other than in
prototyping. I am happily waiting until the final nail is put on the coffin of
this overhyped, flawed relational store."

Point being you can say just about the same thing about any other database.
They are all flawed for one reason or another. I happen to like Mongo quite a
lot, but I rarely use it. You need to understand what situations it works best
in and it's unfair to both it and yourself to generalize and wish it dead.

~~~
flavio81
Oracle RDBMS isn't flawed. It is expensive, complex to
configure/mantain/extend, expensive in licensing, expensive in storage, and
also expensive. Did i mention expensive?

PostgreSQL is eating Oracle's customers little by little.

RDBMS aren't flawed at all, this is technology that has been perfected for the
last 40 years. What is flawed is to think that relational data can be easily
stored on a document store (typical mistake).

I think document stores are a great thing; the only problem is that MongoDB
isn't a good document store.

~~~
STRML
> I think document stores are a great thing; the only problem is that MongoDB
> isn't a good document store.

To add to that - you know when you need one. If you don't know you need a
document store, you don't need it.

When you try a good document store, like Solr, you realize how appallingly
limited Mongo really is. It's not suited for any practical use outside of demo
apps.

~~~
threeseed
Solr is not a document store. It's a search engine.

If you actually tried using it as one you would realise how ignorant your
comment is. Both the Solr and ElasticSearch have gone on record before stating
that it should never be used as the source of truth.

~~~
tinix
THIS, so much this!!!!

I'm working on overhauling (rewriting, from scratch) a project right now where
the previous developer decided in his infinite wisdom that using ES as a
database was a good idea.

I have tried repeatedly to explain to him, and the product owner, why using a
search engine as a storage database is a horrific idea. Owner gets it, dev
doesn't. I asked that dev if he could overhaul the project, what would he do,
and he said "not use SQL at all, and use ES 100%". <_<

I think this is the problem with Mongo too... you have people misusing it, and
then want to throw the baby out with the bath water and act like Mongo is the
problem, when really, the problem is how they are using it.

------
meesterdude
A really great writeup. A revealing exploration of the perils of mongoDB, and
of the greater issue of selecting technology for a project.

There is never any mention of usecase, in companies. Everyone is still trying
to be google or facebook, and uses "their tools" without a use case for why.
It's just because that's what everyone else does.

All technology has a place somewhere for some use - but we need to know why we
are choosing them.

For example, I choose Ruby on Rails because of it's gains in productivity,
reliability, security and pleasure of use. I can quickly sling maintainable
code that can scale up to millions of users. And most importantly, I don't
have to make a lot of decisions. Best practices are defaulted into the
framework. Some people shy away from frameworks, favoring "simpler" tools -
but that only means they have to re-solve all the problems the framework has
already solved.

Likewise, with MongoDB, all those useful things SQL databases do for us need
to be resolved. But, that's a database decision, and many people making the
decision are just developers in search of a data store. Transactions and ACID
are often not even on their radar.

Overall, i think this is a symptom of a lower barrier for entry. Where before
you needed a CS degree to be a programmer, now you just need to go to a
bootcamp. People are not properly trained, aware (or interested) in the
underpinnings like databases, networking or security - and to their own peril
and the peril of the companies they work for.

------
nemild
(I’m the author of this series)

Eliot Horowitz (HN: @ehwizard), MongoDB’s current and founding CTO, reached
out after my last post - and spent two hours providing feedback last week in
Palo Alto. It was an expansive discussion, and Eliot was reflective and eager
to understand the perspectives I had heard. He noted how much it mattered to
him what HN thought.

I left with tremendous empathy for the challenges of building a venture-backed
database company - while we also disagreed in a few key areas. As engineers, I
hope we continue to have thoughtful, if spirited discussions, like Eliot and I
had - where we both are open to being wrong and have a desire to understand
differing viewpoints.

In the interest of length, I didn’t write the whole interview into my series,
but wanted to share key parts of our discussion on HN:

\- NoSQL: I felt that NoSQL was overhyped in the early 2010s - and that
10gen’s marketing claims were overblown. Eliot argued that many of NoSQL’s
benefits have been realized and that 10gen’s early marketing accurately
reflected the changes to come. For example, while he doesn’t love the term
NoSQL for its impreciseness, he feels that both the JSON-like data structure
and horizontal scaling are here to stay and were in fact the key changes NoSQL
led to (not the SQL DSL). In that sense, he argues that Amazon RDS is a form
of NoSQL today - and that NoSQL had a powerful impact on the roadmap of
existing SQL databases.

\- Data Loss: I generally have stayed away from talking about the
controversial examples of MongoDB data loss in the earliest days (there are
several of HN posts that note this). I know personally of only one team that
lost data, but it’s always hard to understand if this was a database issue -
or their own mistakes. I did ask Eliot explicitly about this, and he said that
these were exceedingly rare.

\- Defaults: I feel like it’s playing with fire to set bad defaults in a
database - with numerous data breaches due to 10gen’s early decisions on
authentication, remote login, and encryption (see for example,
[https://snyk.io/blog/mongodb-hack-and-secure-
defaults/](https://snyk.io/blog/mongodb-hack-and-secure-defaults/) ). For
auth, Eliot argues that developers need to take responsibility for exposing
MongoDB on public servers - and that the SLA for a self-hosted instance is
different than a managed instance (at minimum, I have issues with users having
their data exposed to the world through no fault of their own). He disagreed
with 10gen’s decision to turn on auth by default in later self-hosted versions
once MongoDB ignored remote connections by default (but thought this was the
right choice for the managed Atlas service). (But before 2014, the default
behavior was no auth - and accepting all remote connections, see
[https://snyk.io/blog/mongodb-hack-and-secure-
defaults/](https://snyk.io/blog/mongodb-hack-and-secure-defaults/) ; Eliot
notes that this took a while because changing the default would have caused
issues for existing customers)

I do have concerns when 10gen explicitly targets junior developers (to be
fair, he could never have predicted the growth of Node and the interest in the
backend for frontend engineers). What he says makes sense say 20 years ago,
but with 25% of new software engineers coming from coding bootcamps with non-
engineering backgrounds, I worry that defaults matter ever more in dev tools
(and even seasoned engineers may mess this up, if they’re coming from a
database with different defaults). We discussed analogies like seat belt
lights versus the responsibility of passengers to know better. He also argued
that waiting to get all this right - not just auth - would impact database
innovation, while I think there’s a balance that gets us a lot of the low
hanging fruit (like security).

\- Mistakes with MongoDB: Eliot felt that certain posts (such as Sarah Mei’s
popular HN post about Diaspora:
[https://news.ycombinator.com/item?id=6712703](https://news.ycombinator.com/item?id=6712703)
) misunderstood how to architect MongoDB. Regardless of the particulars, I
think that new technology is especially susceptible to issues like this until
the community develops broader knowledge. The failure states are well known in
many relational databases and there is a broad base of knowledge about how
best to architect relational data models. As startup engineers, we have to
weigh tradeoffs of new vs old tools, with some new tech being game changing
for startups (see PG’s much cited post about the benefits of new languages
like Python:
[http://www.paulgraham.com/gh.html](http://www.paulgraham.com/gh.html) ) while
many others are hyped new tech that damages startup productivity.

\- SLAs are hard in databases: Early products make choices that customers get
used to (unacknowledged saves), and you can’t quickly just change the default
behavior, esp in a database. 10gen’s early customers loved not waiting for the
writes, and only later did 10gen realize that this was an issue for others
(the default is very different in nearly every other database). To migrate
their first customers without dislocation, they had to hold off on changing
the default behavior for longer than they wanted to. In Eliot’s view, their
competitors would unfairly argue that this default was a way to juice
benchmarks, hoping to stoke anger at MongoDB and cut into their growth. (I
tend to have sympathy for 10gen’s perspectives, with the controversial,
mistaken benchmark that I referred to in part 1 looking to me like an honest
mistake)

Generally, he felt that the issues with MongoDB were few and far between - and
that the benefits of MongoDB was game changing for so many startups. Many of
them would not have survived without MongoDB.

I’ll add some more notes from the interview in part 3, where I go into 10gen’s
early marketing. I also let Eliot know that I would be happy to
share/publicize any broader responses/critiques he writes, so that we can have
a thoughtful debate that benefits others (and he can point out issues in my
arguments).

(Apologies in advance if I’ve made mistakes in representing Eliot’s views)

~~~
eip
> In that sense, he argues that Amazon RDS is a form of NoSQL today

Lol. What?

RDS is literally hosted RDBMS SQL databases.

~~~
nemild
I had a similar reaction.

------
spchampion2
This brings back some memories from 2012. I was updating an internal tool at
the company where I worked, and after a lot of thought I decided to replace a
tried and true MySQL database with Mongo. It really seemed like a good idea at
the time - we were storing loosely related documents where not having a fixed
schema was an advantage.

Any advantage I got was lost by the time I built all the logic to handle the
joins I did need to make (those join keys weren't so schemaless after all).
And then I needed logic to make sure every record had the right keys, that
they made sense, etc. This was all stuff that MySQL had been doing for me.

But the real kicker was that Mongo made my performance worse. When I migrated
my database (roughly 10 million records), I compared before and after sizes of
the actual files. Mongo's were 2-3x the size. I didn't realize it before
starting, but Mongo's preallocation model gave me huge files with sparsely
written records that had room for future updates. But I didn't need that extra
room because my data rarely changed. So I ended up with larger files that took
longer to scan for unindexed queries (mostly for reporting), which meant I had
to index more stuff, which increased my memory usage, and forced me to upgrade
to larger servers.

Had I stuck with MySQL, I would have been fine. Many expensive lessons were
learned from this, which I guess was valuable.

------
cmenge
I'm a long-time MongoDB user and largely a fan of it because I believe the
interface is superior to some text-based SQL statements.

But whatever DB you like, if you move the state of your application to another
application (i.e, a database) you better make sure you really understand how
it works.

For SQL databases, many people think they know how they work, but
misconceptions seem widespread. Essentially, many beginners believe that SQL
databases guarantee serializability everywhere and all the time, relying on
the database (and OR-mappers) a lot / too much in my opinion.

Choosing a system that only offers very few guarantees forces you to think
about them more explicitly. On the other hand, if you never bothered to
understand SQL, you probably won't bother understanding anyDB's restrictions
and guarantees either, and then everything goes to sh*t.

Some databases might be easier to understand than others, but I feel MongoDB
is on the 'easier' end here. YMMV.

~~~
winter_blue
Couple of points:

1\. _ORMs_ I'm not sure why you dismiss ORMs. Have you ever used a good ORM?
There are a lot of high-quality ORMs out there, that do the heavy lifting,
provide type safety, and take care of the boilerplate. There is no reason to
write text-based SQL anymore.

2\. _Relations:_ Foreign keys are incredibly useful. They're the biggest
feature I miss out in relational databases. They help keep your data in a sane
state. If a user deletes his account, you can configure your database use a
_DELETE CASCADE_ to automatically remove all data associated with the user.

3\. _Normalization:_ NoSQL databases encourage you to denormalize your data.
I've seen NoSQL databses frequently run into problems with stale data, with
date that is duplicated and not kept updated, where you have multiple out-of-
sync version of the same piece of information. With NoSQL database, you have
to handle all the complications of denormalization. ( _You_ , the developer,
have to remember to update/delete/etc from the multiple places the same piece
of data lives in.) The database doesn't do it for you. (The database is a dumb
key-value store, nothing more.) Relational databases encourage keeping the
logical design of your databse normalized. To quote Wikipedia: "The preferred
method is to keep the logical design normalised, but allow the database
management system (DBMS) to store additional redundant information on disk to
optimise query response. In this case it is the DBMS software's responsibility
to ensure that any redundant copies are kept consistent. This method is often
implemented in SQL as indexed views (Microsoft SQL Server) or materialised
views (Oracle).".

4\. _Schemas:_ The worst thing about NoSQL is the absence of an enforced
schema. Schemaless databases are a scourge. There's always a schema -- it's
just that it's scattered all over the code. If you are joining a new company,
you have to sift through piles of code to figure what the structure of the
data is. Schemas are like types, and my dislike for dynamically typed
languages carries over to schema-less database. Relational databases make you
think carefully about the schema, and specify the schema explicitly.

In the end, you end up needing to do a lot of extra work, likely end up with
more unstable and buggy system, just to avoid the small amount of _totally-
worth-it_ upfront work that setting up a relational database requires.

~~~
zer00eyz
As someone who thinks both systems have their place, there are a few issues in
your arguments:

1\. ...There is no reason to write text-based SQL anymore.

There sure is! Unless your schema is dead simple your going to run into places
where hand tuning is a requirement. Lots of ORM's are third rate at best,
people swear by them but don't have complex data that would make one throw
fits.

3\. Normalization: NoSQL databases encourage you to denormalize your data.
I've seen NoSQL databses frequently run into problems with stale data, with
date that is duplicated and not kept updated, where you have multiple out-of-
sync version of the same piece of information.

Nosql doesn't encourage you to de-normalize, and there are reasons to de-
normalize in an RDBMS. Denormalization when done right should NOT result in
duplication, if it does your doing it wrong. Both systems are afflicted by
these poor choices. It is easier to screw it up in a document store like
mongo.

4\. Schemas: The worst thing about NoSQL is the absence of an enforced
schema... If you are joining a new company, you have to sift through piles of
code to figure what the structure of the data is...

Again were not talking about a problem that is exclusive to document stores.
You can just as easily have queries all over the codebase that make changing
your RDBMS hard. People also do very stupid things like throwing giant json
blobs (and before that xml) into their RDBMS and expect it to work. However a
schema makes dealing with data apart from your application a much simpler
task, unless you throw all those rules out the window, and a shocking number
of people do.

~~~
alexvy86
> Denormalization when done right should NOT result in duplication

Isn't that what it is by definition? Can you give an example of how would you
denormalize without causing some sort of data duplication?

~~~
zer00eyz
There are two main reasons to denormalize: security, and performance.

The former (security) is something I have only ever had to deal with twice. If
your going to cordon off data based on some arbitrary ruleset (3rd party) it
is a path you can take. For transactional integrity, and from an operations
perspective both cases were perfectly valid.

The latter is one I have also only seen rarely.

I have seen it done to keep a history of actions without cluttering up the
primary table. As an example I worked on a DB with millions of entries for
users, and a separate table for emails, when the user updated their email, it
would add a new row, verify it and then fetch the newest complete row when the
user was queried. Getting rid of all the history in that table provided a
fairly significant performance bump.

The second was to split little used columns in a single table out from the
frequently accessed ones. The resulting trimmed table then fit in memory and
was orders of magnitude faster than going to disk.

Is there ever a case to denormalize and duplicate? There are a few:

OLAP systems are unique beasts, and duplicate and denormalize in many a
strange way, and all in the name of performance and ease of use for end users.
The reality is that these systems usually have a SINGLE point of entry for
adding and updating records (that aren't materialize views of end users). OLAP
systems are weird, because nothing makes sense in them, but most of them (with
all their duplicate data) aren't primary stores. Oddly I have replaced a
handful of OLAP RDMBS with document stores...

The other major reason to duplicate is for "snapshotting". If you need to know
the state of one record when another record was created then your probably
going to end up with duplicate information. IN every case where I have seen
this the words "compliance" and "audit trail" are part of the conversation.
However rather than being problematic the decoupled nature of the duplicate
record is desirable.

------
hitgeek
nothing much new here.

mongodb marketing/PR was a problem, advertising a general purpose RDMS
alternative without the technology to support it.

users were also a problem, using a technology without understanding the
architecture and trade-offs.

to be over critical of "mongodb" though is unproductive. there were a lot good
people working on new software to solve hard problems and I'd like that to
continue.

lets just not repeat the same mistakes. don't get caught in marketing hype,
and carefully evaluate technology decisions.

------
mnm1
'One 10gen engineer made this point in analogizing SQL to Cobol, arguing that
"SQL is Annoying":'

Why wasn't this the tagline for Mongo to begin with? At least it shows the
arrogance, ignorance, and outright stupidity behind the database. This is not
an engineer's comment. It cannot possibly be now, decades after SQL has become
a de facto standard for some very good reasons (outlined in the article and
elsewhere, won't rehash here). It is a marketer's comment, probably spoken by
an engineer who isn't qualified to build simple demo apps, let alone anything
as complex as a database. Mongo's CTO seems to fit this bill of marketer more
than anything else or how would he be able to make the claims he makes with a
straight face?

Our industry has a problem with fads and decisions based on feelings. Even if
SQL is annoying, it's incredibly stupid to base your tech choices on feelings.
It's even dumber to choose a product whose engineers build the product based
on feelings. Last I checked, I thought we were an industry of engineers,
trying to apply scientific principles and some human ingenuity to build
software. Where does 'annoying' fit into that? Or other adjectives I often see
thrown around on these boards like 'clean' and 'slick'. I know it's hard to
quantify the quality of software and speak about it with any coherence, but
this is beyond incoherent. 'Annoying' as applied to SQL tells me nothing.
'Annoying' as applied to the engineer making this incredibly stupid comment
tells me that this engineer is either lazy, gullible, or just downright
stupid. Have we seriously lost our ability to discern hype from reality that
we let people and companies like this dictate our technology choices, throwing
out decades of solid research in computer science for what some idiot at a
company more specialized in marketing and PR than engineering tells us?

I'm willing and ready to hear well-thought out criticism of SQL and RDBMS.
What I'm not willing and ready to hear is some idiot's feelings about SQL or
RDBMS. You want to make a claim? Measure it. Present a report with data. But
goddamn, if one of my reports came to me with this kind of stupidity, I'd give
them a chance, but if they persisted, I'd fire them. This isn't revolutionary
thought. It's not evolutionary thought. It's lazy idiots who don't want to
learn SQL, a language so easy even business people with essentially no
computer skills can pick up.

------
eberkund
What about for IoT devices? I could see NoSQL still having a place there,
although I could also see it working just as well with a SQL database.

~~~
mbreese
What is special about IoT devices that make them more suited towards a NoSQL
solution? Scale? Is that really an issue for the majority of IoT deployments?

~~~
eberkund
Scale and also the data structure is often times very flat; usually just a
bunch of records from sensor readings.

------
yinso
> Schemas: Schemaless does not mean no schema; instead, it means an implicit
> schema in the app (a particularly challenging misnomer for anyone outside
> our industry)

Still a challenge for many in the industry.

------
kenwalger
These "Why technology X is worthless" types of posts and statements always
give me a bit of a laugh. As with most technologies, there is a) a learning
curve, and b) best practices to follow.

Many of the comments here seem to discuss a few things which, in my opinion,
lead me to believe that the implementation is incorrect or decisions are being
made on old data or based on older versions of MongoDB. Making arguments
against any product based on previous versions seems to be counter productive.
Most of the posts here don't make reference to a specific MongoDB version, but
many reference their experience with the product in 2012.

Assuming that these experiences were at the end of 2012 with the most current
at the time version, we are still talking about version 2.2.2. The current
stable version is 3.4.6. As you can imagine, there have been many advances to
the product in five years. Basing one's knowledge and opinion of MongoDB on
old versions doesn't seem logical. Even back in 2012 though, there was a lot
of misinformation about MongoDB. A blog post from that time period
([https://blog.serverdensity.com/does-everyone-hate-
mongodb/](https://blog.serverdensity.com/does-everyone-hate-mongodb/)) argues
some of that information at that time.

Many other comments were made based on what seems to be a lack of spending
time with learning MongoDB. It is a non-relational document store. It is NOT a
relational database. It requires a different way of storage design and
thinking and attempting to force MongoDB to be a SQL-like database is silly.
SQL is indeed a popular option and can work well.

However, non-relational databases work well too. There are lots of
implementations of it across a lot of companies. A few relatively recent posts
are good examples [https://engineering.snagajob.com/mongodb-in-aws-does-it-
real...](https://engineering.snagajob.com/mongodb-in-aws-does-it-really-
work-a705b3da07a2) and [https://mongomikeblog.wordpress.com/2016/04/29/why-we-
went-w...](https://mongomikeblog.wordpress.com/2016/04/29/why-we-went-with-
mongodb/) That doesn't account for many of the large companies out there using
it, like Expedia, Facebook, Forbes, to name a few.

If we want to have a discussion about specific, current, features of MongoDB,
that's great. There are a lot of them. Many have been mentioned. Some have
been mentioned as a negative due to what appears to be poor implementation. If
we want to debate pros and cons of any product, we should be sure that we are
talking about how things are intended to be implemented and not some hacked
together approach.

Perhaps the marketing spin was too aggressive. I'm not a marketing person.
I'll leave it to Mr. Horowitz to backup his claims. But if we are going to
have a discussion about the pros and cons of MongoDB, can we at least agree to
not talk about old versions? I mean, I had a bad experience with Windows 3.1,
so should I not use Windows anymore? ;-)

