The Road to CouchDB 3.0: Prepare for 4.0

This is a post in a series about the Apache CouchDB 3.0 release. Check out the other posts in this series.

In early 2019, the IBM/Cloudant team proposed a major change to CouchDB: replace the storage and clustering subsystems with FoundationDB.

The reasoning is straightforward: how much effort would it be to bring the existing underpinnings into the 2020s and beyond? Are there alternative options? Can we use something that exists already?

After about seven months of diligent research, design and planning, we concluded that it would not only be feasible, but also beneficial to CouchDB to make the move to FoundationDB.

We have a lot more to say about this in the future, but if you want to follow along at home, check out the RFCs where we discuss the various technical details.

One of the consequences for moving foundations (pun!), is that the new one is built on different tradeoffs than the old one, which has served us very well so far. This in turn leads to certain limits that we’ll have to impose on certain operations in CouchDB 4.0 and beyond.

Since it is beneficial to keep to those limits already in 3.0, and to make the transition to 4.0 easier in the future, we have introduced, or reduced limits to certain things in CouchDB in line with the limits we believe that CouchDB 4.0 will have.

If you need to go beyond those limits, they are configurable for all of CouchDB 3.x, but won’t be configurable at all in 4.x.

For now, the only limit we’ve added is max_document_size, it drops from 4GB, which was a theoretical limit to begin with, to 8MB, which is much more reasonable in terms of CouchDB performance.

The Road to CouchDB 3.0

This is the first in a series of blog posts introducing the Apache CouchDB 3.0 release.

The CouchDB 3.x series of releases is going to be the best we have ever released using the “Classic CouchDB Architecture”. Of course, the newest releases should also always be “the best”, but in this case, we really mean it.

2.x finally fulfilled CouchDB’s original vision of a replicating, clusterable, highly scalable data store that is easy to use, and it was rather successful at that.

The main focus of the 3.x release line is addressing most of the shortcomings that our otherwise happy users have reported over the past years.

The 3.x release series is particularly focused on a few areas of improvement over 2.x:

  • Security
  • Missing, obvious features
  • Even smoother operational behaviour
  • Prepare for CouchDB 4.0

Coinciding with the 3.0 release, we are dedicating a blog post to the changes in each of these areas:

Let us drill into what “Prepare for CouchDB 4.0 means”, because we can’t properly describe CouchDB 3.x without talking about CouchDB 4.x. Earlier, we mentioned “The Classic CouchDB Architecture”. What do we mean by that?

In CouchDB 4.0 and beyond we are going to take the tried and trusted underpinnings of CouchDB: the append-only B+-tree storage engine and the dynamo clustering layer, and we are going to replace it with FoundationDB.

There will be more blog posts explaining the details of that future release, when the time comes. For 3.x, we need to know that a big change is coming, so we have both an incentive and an opportunity to build the best version of CouchDB on the existing architecture, and that a number of changes are going to prepare our users in 3.x for this future migration.

But as with all CouchDB releases, past, present, and future, we are going to focus hard on strong API compatibility, so your applications can start using the newer features without being rewritten.