After our abortive attempt to port CouchDB to FoundationDB a few years ago, we now have a number of new features available or landing soon that in summary would make a good cut-off point for calling the result CouchDB 4.0.
The narrative frame that came to my mind is that this set of features “(finally) resolves the major issues people might have with CouchDB”. Not saying everyone runs into these issues, but once you do, the consequences are rather annoying and it would be great if normal CouchDB use didn’t lead there in the first place. ## Features In particular, I am thinking of these flagship features: - tombstone deletion via the new time-seq (landed in `main`) - reducing intra-cluster conflicts via selecting a primary node for writes (https://github.com/apache/couchdb/pull/5371) - the need to run database-per-user as solved by per-doc-access-control (https://github.com/apache/couchdb/pull/5842) - faster validated writes with declarative VDU (https://github.com/apache/couchdb/pull/5839) - reduced IOPS- and data storage needs with generational compaction (https://github.com/apache/couchdb/pull/5583) - modernised Search allows to run on modern JVMs, and also Nouveau (3.5.x and `main` respectively) - truly non-blocking writes with parallel preads (3.5.x) [these just of the top of my head, if you find other features that support the narrative, please do respond :)] ## New Defaults In addition, during the development of the 3.x.x series, we have started adding new sensible configuration settings that we kept OFF by default for backwards compatibility, that we now can turn ON by default. With the option of folks switching the config back if the need that compatibility, but opting new users into sensible defaults. I don’t have a list of this handy, but I plan to set up a milestone on GitHub where we can collect these. ## Deprecations and Removals Similarly, we can finally remove things we have marked deprecated for a good while now (show, list e.g.) and we have a chance to mark other things as deprecated in future 3.x releases that we then remove for 4.0. The big one here is supporting SpiderMonkey as the JS engine for CouchDB. We now have a viable contender with QuickJS that is operationally superior and we have a lengthy transition period for people to make the move. And for most users, it’s a seamless transition and only very few folks will have to rebuild their indexes, which can happen slowly and in the background. SpiderMonkey is causing considerable issues when packaging CouchDB with RHEL10 packages already having switched to QuickJS-only because of SM-unavailability. In conclusion, it is time to remove support for SpiderMonkey. ## Timeline and Releases Again, I’ll also set this up in GitHub so we can collaborate on tracking progress, but here’s my rough suggestion for what a release timeline could look like: - 3.6.0 ships what is currently on `main`, is blocked by a per-db config API (https://github.com/apache/couchdb/issues/5685). Also deprecates SpiderMonkey. For each of these in-progress features, I am envisioning a point release, but as some might land at the same time, we don’t have to artificially split them up into separate releases, but these are: - reduce intra-cluster conflicts - per-doc-access - generational compaction - mango VDU + advanced selector features These could map neatly onto 3.7, 3.8, 3.9 and 3.10, but as I said, we might coalesce some of these. 4.0.0 then: - removes SpiderMonkey, makes QuickJS default JS engine - enables auto-tombstone removal by default - enables generational compaction by default - swaps TBD configs to ON by default This should give everyone ample time to make a migration and make 4.0.0 as safe to upgrade to as our previous major versions past 2.0.0, as we do not introduce any incompatibilities that could not be adjusted to leading up to the release. — What do you all think of this plan? Best Jan —
