janl

Thanks Paul, I’ve updated the post to clarify: https://neighbourhood.ie/blog/2025/02/26/how-couchdb-prevent...

I would still recommend you give CouchDB and PouchDB a fair shot. They are used successfully by many folks.

No offence taken, SQLite is great technology :) — My company makes a (commercial) CouchDB add-on based on SQLite to add SQL queries to CouchDB (link provided for informational purposes): https://neighbourhood.ie/products-and-services/structured-qu...

fixed, thanks

it _supports_ one for a specific legacy users, the default is more modern.

Yeah we are working on that. Sometimes it is hard to get public info out of private projects, but there’s going to be a bit more on that in the not so distant future :)

The Mac version is probably closest to what you mean, but yeah, an “Access/FileMaker“ type of app, most easily realised by bundling CouchDB and Electron probably, would go a long way. If anyone needs a project ;)

still does (in a limited capacity :)

CouchDB dev here. 2.x only added new features, not sure what you’re referring to that was removed. The only on incompatibility was the changes feed ids moving from numbers to strings, which is hardly a huge migration :)

CouchDB dev here. While that was our idea early on for a while, we have loooong (10+ years) moved away from this narrative.

CouchDB is a document database that can be essentially indefinitely clustered to grow and shrink with your application / traffic demands.

It also comes with a unique replication protocol that allows you to synchronise casually connected instances (say offices around the world, or mobile devices and a cloud) much more like git uses push & pull. No other database really puts that into an open source / open government project.

There’s tons more cool stuff that CouchDB does and its being used in mission critical infrastructure that you’re relying on every day :)

I’m the author and this is the correct reference.

Good observations, let me add the current state to that:

> Querying in a more ad-hoc way (vs. building indexes ahead of time and querying by key, etc) is a bit janky / not 1st class (I think mango addresses this but not entirely sure).

Mango does address this.

> The JS query server engine is/was fairly old

On the one hand, running an old JS engine isn’t big trouble for CouchDB, especially with transpiration tools available, but we now support modern SpiderMonkey up to version 91. The main benefit for CouchDB users is modern JS syntax being available.

> The authorization model is... unique.

per-doc-auth is in the works, no ETA, and the first iteration is going to be limited, but it’ll address the main issues for db-per-user users.

not really, no.

the difficulty starts happening when something goes wrong. FDB has a lot of moving parts (for good reasons, this is not to speak ill of FDB), and that conceptual complexity is a lot more what CouchDB has today with its very basic Dynamo sharding model. Resolving issues with CouchDB is also not trivial, make no mistake, but there is generally a lot less going on.

the work is all open source on the CouchDB main git repo.

sure, changing defaults for different use-cases is totally normal for any database. Best thing: CouchDB 3.x comes with shard splitting and default shard factor of 2 (previously 8), so you get best of both worlds getting started, and you end up with larger dbs you can split their shards on the fly.

the ASF switched binary hosting providers, the COuchDB docs have the up to date links: https://docs.couchdb.org/en/stable/install/unix.html

CouchDB is a lot more scalable than SQL databases because it has a distributed scaling model built in (just add nodes), no need to mess with read-replicate and finicky hot-failover, it all just works out of the box (Dynamo style).

CouchDB docs have you covered: https://docs.couchdb.org/en/stable/replication/intro.html

syncing between clients requires a network between clients and normally, clients only have connections to servers. But if you are in a situation where clients can open TCP connections to other clients, CouchDB can sync over that.

CouchDB dev here, I can confirm that CouchDB is very much not on life support. Active work goes into PouchDB and CouchDB, some of which is addressing the issues brought up here. Nothing shipping yet (aside from maybe native jwt auth in this months 3.2.0 release), but definitely ongoing :)

Yup, works with clustering and everything: https://blog.couchdb.org/2020/02/26/the-road-to-couchdb-3-0-...

You can replicate all per-user DBs into a central database today.

We are working on per-document-access-control at the moment, to support this use-case out of the box

We use https://github.com/jo/couchdb-bootstrap successfully.

CouchDB does SSL natively, but we do recommend HAProxy.

I sadly can’t name names, but rest assured the fortune 500 is heavily involved.

OTOH, publicly known big companies using CouchDB include Apple and IBM.

And I worked on a team that used CouchDB’s offline capability in the 2015 Ebola crisis in West Africa. That work also lead to the first Ebola vaccine ever.

That’s why we do CouchDB :)

MongoDB raised $311M in funding and is now a publicly traded US corporation: https://www.crunchbase.com/organization/mongodb-inc#section-...

CouchDB is a community-run Apache Software Foundation project (that has corporate contributors as well as individual contributors) at a much lower scale than MongoDB.

Of course MongoDB’s marketing is better, they are spending a lot of money on it. If you’d like to help out with CouchDB’s marketing, we can always use another helping hand :)

last time I looked, realm did “last write wins” “conflict resolution”, which is just marketing speech for “randomly losing customer data”, which is something CouchDB decidedly works very hard to never ever do ;)

> At this point why would you use CouchDB over something like MongoDB?

They are very different databases. But since they have come up are around the same time and because they look very similar on the surface, you might think you chose between them.

But when you look more closely at detail decisions on the technical details, at almost every point, where CouchDB goes one way, Mongo went the other way.

I’m not saying either decisions are better or worse, it’s just that they are very different database that you should evaluate on their merits, not just superficially.

<3

FoundationDB got re-released as an open source project: https://www.foundationdb.org/blog/foundationdb-is-open-sourc...