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 ;)
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 :)
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.
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.
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.
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).
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.