
CouchDB vs. MongoDB - yanivleven
http://blog.panoply.io/couchdb-vs-mongodb
======
candeira
The article is strangely outdated on the CouchDB side, like someone wrote it
two years ago.

It fails to mention that CouchDB now has Mango, which is a MongoDB-compatible
query language.

Since 2.0, CouchDB also has Dynamo-like clustering thanks to Cloudant's open
sourcing of the BigCouch code.

I wonder if the MongoDB side of the comparison is more up-to-date, or equally
stale.

~~~
nevi-me
Mango seems interesting, thanks for that. I got thrown into a tight spot at
work, where I'm building a lease calculator for the accountants, I need to
build the whole thing as a self-contained application, due on Monday. Long
story is that it wasn't as easy as I thought, and I ended up having to
replicate Journal entries, a trial balance and financial statements. Even
though Mongo doesn't have transactions, I found a good way to make my journals
balance. I'm using aggregating framework to post journals to TB and FS.

The last part I was worried about is the self-contained bit, so I'm going to
give CouchDB a try, and use Mango to prevent redoing everything

~~~
6nf
You don't need a different NoSQL database, you need a relational database.

------
brianpgordon
No mention of Mongo "/dev/null as a service" DB's infamous issues with data
loss?

Apparently their new replication protocol isn't as utterly broken as the old
one, but my understanding is that data recovery after server crashes is still
a problem.

~~~
btown
I ran into a doozy in our production Mongo 3.2 replica set just this week,
where initial sync completely failed because the oplog was growing too fast.
It seems this class of errors was actually fixed (
[https://docs.mongodb.com/manual/core/replica-set-
sync/#initi...](https://docs.mongodb.com/manual/core/replica-set-
sync/#initial-sync) ) in 3.4, which also fixed a number of the data
reliability issues you mentioned (see
[https://jepsen.io/analyses/mongodb-3-4-0-rc3](https://jepsen.io/analyses/mongodb-3-4-0-rc3)
). But since we hadn't upgraded, the only way to fix things was to throttle
back our write-heavy background tasks during a period of low usage -
definitely not the kind of thing you want to have to explain to users.

At the end of the day (see my other comment in this thread), I'm bullish about
the developer experience of Mongo/Meteor, and I think that 363 days a year of
significantly increased developer productivity is worth the 1 day of devops
hell that might ensue from that stack choice, and 1 day of realizing that your
performance problems all stem from Mongo query performance being much more
reliant on manually creating indices on fields vs. an unindexed Postgres table
of the same size. Sigh. On the reliability end, it helps that our (largely
append-only) data model is such that inconsistencies are possible to clear up
manually if needed. But on those couple days a year, I'm definitely not a
Mongo fan.

~~~
zepolen
I've seen this 'increased productivity' argument for Mongo over and over but I
just don't see it in practice.

I've dealt with many apps and teams that use Mongo, and the amount of time
spent tracking annoying bugs because of a lack of schema, writing migration
scripts and the _abysmal_ performance of the database leads me to believe that
the only reason Mongo devs think they are more productive is because they can
get 3 lines of code to make a new collection + record in the database in 5
seconds, and ignore the 5 months of time they spent down the line.

------
btown
> Mobile support: CouchDB stands out, in that it can run on an Android or iOS
> mobile device. In addition to being mobile, the database can also
> synchronize with a remote master database, allowing the data to be shared
> easily between mobile devices and servers.

Meteor actually provides exactly this for MongoDB; it has a "minimongo"
package in the browser that supports Mongo's query language, running it
synchronously against an in-memory copy of the collection [0]. And with
Meteor, you can specify "subscriptions" declaratively that enable
bidirectional synchronization while their owner components are in scope.

Mongo certainly has some reliability issues (see other comments here) but I've
yet to find a full-stack system so painless to develop in, _especially_ if you
need realtime support. With things like ToroDB Stampede [1] and a general
approach of "write all your code in React with Meteor dependencies factored
out into containers," there's a clear migration path towards the relational-
based separate-backend-frontend world when you need to go there.

[0]
[https://guide.meteor.com/collections.html](https://guide.meteor.com/collections.html)

[1]
[https://www.torodb.com/stampede/docs/1.0.0-beta2/about/](https://www.torodb.com/stampede/docs/1.0.0-beta2/about/)

~~~
matharmin
The CouchDB one is actually a fully persisted database, not just an in-memory
cache. Both are useful, but it's not quite the same thing.

~~~
WorldMaker
Plus the CouchDB ecosystem has Couchbase for iOS/Android (with their own
tradeoffs versus mainline CouchDB) and PouchDB which is a JS version of
CouchDB that runs in the browser on just about any platform and can store
directly in IndexedDB.

------
Florin_Andrei
CouchDB replication has got to be among the easiest and nicest in the
industry. Setting up master/master is a breeze.

------
passwordlost
> Snapshots: Any changes to a document occur as a revision and appends the
> information to the file. This means you can grab a “snapshot” of the file
> and copy it to another location even while the database is running without
> having issues with corruption.

This is the main feature I sell when pushing CouchDB.

Use it to project events and you'll see what I mean.

~~~
assafmo
On the other hand, with v2 sharding it's acctualy harder to pass this file(s)
around and can be documented better how to do so successfully.

------
lunaru
I want to make an obvious point, but I know it confused me quite a bit for a
while, so just in case it helps anyone else: There's CouchDB and then there's
Couchbase which is similarly named but completely different.

I recommend anyone shopping for databases with easy master/master replication
with eventual consistency and no single points of failure to consider
Couchbase as well. It's not the same will have it's own set of pros and cons.

~~~
ddorian43
Couchbase is not eventually consistent

------
AdrianRossouw
I really liked this article for this kind of thing :

[https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-
redis](https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis)

------
koolba
> MongoDB is schema-free, allowing you to create documents without having to
> first create the structure for that document. At the same time, it still has
> many of the features of a relational database, including strong consistency
> and an expressive query language.

The author clearly has a different definition of "strong consistency" than
most. I don't see how any claims of consistency (in a data usage, not CAP
sense) can be made of a database that can't properly store a number as a
number or even guarantee that it's a number at all.

Also, does anyone actually like the Mongo query language? It was cute when I
first saw it but I pity anyone trying to do anything complicated by manually
writing those JSON strings.

~~~
threeseed
MongoDB absolutely stores numbers as numbers. Always has.

And yes in a schemaless database you are required to manage the schema in your
application layer as opposed to within the database. If we wanted a database
with a rigid schema we would just use a SQL database.

~~~
zepolen
He said can it _guarantee_ that the field "length" will always be a number and
not..eg a string, or a list, or an object.

~~~
threeseed
Why would it guarantee that ? It's a schema less database. It's not supposed
to do that.

And my point is that if you query a single document and the field is a number
then it will be returned as a number i.e. it physically stores and understands
numbers.

~~~
zepolen
Elasticsearch is schemaless as well, however it can guarantee that a field is
a number once used.

~~~
threeseed
Elasticsearch is not schemaless. It typically requires you to define a mapping
(schema) upfront. You can set it to automatically infer the mapping based on
the available data but this does not make it truly schemaless.

MongoDB allows a free form schema for every document. You're again comparing
apples and oranges.

------
wsxiaoys
One huge benefit by adapting a CouchDB backend is you got replication free,
with PouchDB on client side this opens so many opportunities.

~~~
indolering
PouchDB is one of CouchDB's killer features. During development you can
effortlessly switch between storing things locally, in the browser, and then
sync with a remote database.

------
pbreit
I'd like to see "vs Postgres".

~~~
macmac
Postgres' JSON support is very impressive.

------
hackbinary
We've found the Postgres json store works just fine for our purposes, thank
you very much.

~~~
devrandomguy
The reason I rejected PG's JSON store, was it's inability to update fields
inside of a JSON doc, without replacing the whole document. In your case, does
this constraint push you to use more types of smaller documents, or do you
just read the whole doc, update it in the application, and then write it back
to the DB?

Have you ever had an issue with conflicts, where multiple instances of the app
read, modify and write different things to the same document at the same time?

~~~
edoceo
JSONB data-type allows for specific field modifications in the JSON object.
Operators look ugly in hand-crafted SQL but, works a treat.

------
assafmo
I don't agrre with the article saying MongoDB is better at reading.

From my experience MongoDB is fast, but CouchDB really shines when you have a
read heavy application.

Also the article didn't mention Mango queries, which is a blessing (fast
indexing as erlang views), but in my opinion this feature can be a lot better
with stale results, for instance.

------
brimstedt
I use couch, pouch, elasticsearch and sql dbs. I never really got the
"schemaless" selling point of nosql though.

I do see the point of storing documents rather than rows for some use cases,
or dbs extra strong on searches, etc.

But what is the problem with an "add column" or "change datatype" operation is
sql..?

~~~
bsg75
Partly because MySQL requires a full table lock and full table copy to
implement those operations. Much of the nosql movement originated from
implementing schema changes on production MySQL databases. In many if not most
cases, NoSQL is really NoMySQL.

Many other engines, PostgreSQL for example, can add a new column without
constraints as a nearly instant metadata change only. Data type changes that
do not require validation (expanding a VARCHAR vs CHAR to INT) are also rapid.

------
usuallybaffled
I find MongoDB easier to deploy and maintain because it's easier to build and
monitor. CouchDB with Erlang not so much (for our environment, it's totally
alien).

EDIT: I made a statement about our preference, for our environment. I did not
make broad claims about these DBs for other people. How am I upsetting HN?

~~~
johan_larson
Why do you build your DBMS from source?

~~~
usuallybaffled
Specifically for CouchDB, because packages provided for CentOS/RHEL were
outdated and now they don't even exist.

------
virmundi
Now do ArangoDB vs MongoDB. Given Arango's clustering tools recently, it
should be a fair comparison.

