+1 excellent






From: Jan Lehnardt <[email protected]>
To: "developers CouchDB"<[email protected]>
Date: Fri, 27 Feb 2026 04:00:40 -0500
Subject: (The Return of) CouchDB 4.0



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 
—

Reply via email to