2.2

The Apache CouchDB development community is proud to announce the immediate availability of version 2.2.

Version 2.2 incorporates 8 months of improvements to the already successful 2.1 release series.

For CouchDB < 2.0 users, the main improvements in 2.0 still apply for 2.2:

  • 99% API compatibility- native clustering for increased performance, data redundancy, and ability to scale
  • Easy querying with Mango
  • New Admin interface- Major performance improvements around compaction and replication.

Most importantly, CouchDB 2.0 finally fulfils CouchDB’s original vision of a distributed and clustered document database.

The 2018 Annual CouchDB User Survey has revealed that as of July 2019 98% of our user-base have adopted CouchDB 2.x with about 50% running CouchDB 1.x at the same time.

Note, as previously announced on the developer mailing list, there will be no further releases of CouchDB 1.x. CouchDB 1.x is a fine piece of software and folks with existing installations should be fine continuing to use it, just beware that there won’t be any further bug fixes or security fixes coming. This reflects project reality insofar as that the 1.x line has only received minimal maintenance in the past few years with the majority of the effort going to 2.x.

2.2 Highlights

See the official release notes document for an exhaustive list of all changes.

  • New pluggable storage engine framework. This internal refactor makes it possible for CouchDB to use different backends for storing the base database file itself. The refactor included a full migration of the existing “legacy” storage engine into the new framework
  • The minimum supported version of Erlang is now R17, not 16B03. Support for Erlang 21 is still ongoing and will be provided in a future release.
  • The CouchDB replicator can now make use of the /_session endpoint rather than relying entirely on HTTP basic authentication headers. This can greatly improve replication performance.
  • CouchDB no longer fails to complete replicating databases with large attachments. The fix for this issue included several related changes (GitHub issue 745 et.al.)
  • Multiple queries can now be made at the POST /{db}/_all_docs/queries, POST /{db}/_design_docs/queries and POST /{db}/_local_docs/queries endpoints. Also, a new endpoint POST /{db}/_design/{ddoc}/_view/{view}/queries
  • The least recently used (LRU) cache of databases is now only updated on database write, not read. This has lead to significant performance enhancements on very busy clusters.
  • The revision stemming algorithm was optimized down from O(N^2) to O(N) via a depth-first search approach, and then further improved by calling the stemming operation only when necessary.
  • CouchDB now checks for request authorization only once per each database request, improving the performance of any request that requires authorization.
  • If a user specifies a value for use_index that is not valid for the selector (does not meet coverage requirements or proper sort fields), attempt to fall back to a valid index or full DB scan rather than returning a 400.
  • CouchDB now includes a new builtin reduce function_approx_count_distinct, that uses a HyperLogLog algorithm to estimate the number of distinct keys in the view index. The precision is currently fixed to 2^11 observables, and therefore uses approximately 1.5KB of memory.

  • Much improved documentation. Highlights include:

    • A complete rewrite of the sharding documentation.
    • Developer installation notes (INSTALL.*.rst)
    • Much of the content of the original CouchDB Wiki has been imported into the official docs. (The old CouchDB Wiki is in the process of being deprecated.)

     

  • Much improved Fauxton functionality. Highlights include:

    • Search support in the code editor
    • Support for relative Fauxton URLs (i.e., not always at /_utils)
    • Replication setup enhancements for various authentication mechanisms
    • Fixes for IE10, IE11, and Edge (we hope…)
    • Resolving conflicts of design documents is now allowed

     

  • Many more smaller bug fixes and performance improvements, as well as more features and refinements. See the release notes for a full list.

 

ezInvoice and Client-side Web Apps: an Interview with Bill Stephenson

Bill Stephenson from ezInvoice talked to us about how he first discovered CouchDB and what his experience has been like employing it in applications.

How did you hear about CouchDB, and why did you choose to use it?

We released our first web app, “ezInvoice.com”, back in 2002. It was written in Perl and was getting long in the tooth, but it’s been a solid app and very easy to use, so we wanted to improve on those strong points while adding features that were impossible back then. A friend on the Raspberry Pi forums told me about CouchDB.

Did you have a specific problem that CouchDB solved?

We’d realized early on in creating our app what the makers of CouchDB already knew, that “Self-Contained Data” was a critical concept for documents like Invoices, Quotes, Receipts, etc. When I went to the CouchDB site and started reading the docs I was pretty much stunned. I couldn’t help but feel that CouchDB was built just for us and as I got further into the docs it just kept getting better with features like “replication” and user management and “database per user”.

For the folks who are unsure of how they could use CouchDB–because there are a lot of databases out there—could you explain the use case?

We’re working on a suite of apps for small and medium size businesses. We give the end user software for free and offer “Data Services” as a revenue source for us.  Our data services store their data online “in the cloud”, and make weekly backups and holds them for a month. It lets users access their apps and their data on any internet connected device with a web browser. If they forget to pay, or just cannot pay, for their data services when they expire they still have all their data and their software still works. When they remember or are able to renew their data services everything will be there waiting for them and all their data will sync up and everything will be good again. That’s really another important layer of “data security” for the business owner to consider that’s been overlooked in most “SaaS” and “DaaS” subscription approaches.

I honestly believe that the way we’ve built these apps demonstrates a much better way of doing things, with considerable advantages for the end user.

What would you say is the top benefit of using CouchDB?

Because we use “Service Workers” to store the app code in the web browser’s cache the loads on our server are greatly reduced, and CouchDB mostly only transfers and stores the document data and it’s not a lot of data. So creating a client side web app ends up being much more efficient for both us and the end user and the apps are fast running on the client side. There’s almost no waiting on the server to respond and in fact, we now have a much finer grain control over that interaction.

I found creating an app that runs almost entirely on the client side offers some advantages for the developer I hadn’t really thought about much. For example, it may be considered “bad practice” to dump yet another JS library in the user’s cache but I didn’t really worry much about that. I’m developing and testing on a “Late `09 Mac Mini” and a “Raspberry Pi” and our apps runs fine on both of those. That’s a pretty low bar and I ended up not needing much more than PouchDB/jQuery/Bootstrap to do what we wanted to do. Those tools really offer an incredibly rich feature set and they work together like a seamless API. Coming from Perl I was pretty amazed at how much I could do with that toolset and how easy it is to use.

What tools are you using in addition for your infrastructure? Have you discovered anything that pairs well with CouchDB?

At first I looked at how I could update our old “save” and “get” routines to use CouchDB. I did some web searching for perl modules for CouchDB and in the process I found PouchDB. Going through the PouchDB docs brought on more “Wow!” moments for me. I hadn’t messed with Javascript much but I could see right off the huge advantages PouchDB makes incredibly easy to leverage and that, really, we could and should rewrite the entire app in Javascript so it could run online or offline.

I spent some time looking into Javascript frameworks with an eye towards what would be best for us to use. There’s truly some great ones out there right now, but after going through example apps at TodoMVC.com I just really couldn’t decide which would be best. After stressing over that for a bit I decided to look for what was easiest. We really wanted our apps to be easy for others to modify and to do that we had to keep the bar of entry as low as possible. We ended up using PouchDB/jQuery/Bootstrap for the client side toolset and both the Apache web server and CouchDB on the server side. And with those decisions made I really could “relax”.

What are your future plans with your project? Any cool plans or developments you want to promote?

I’m now looking forward to releasing the 1.0 version of our apps so I can dig deeper into using design documents, views, and even playing with clusters and load balancers. Our goal is to build products and services that make CouchDB incredibly easy to use for anyone at a cost any business can afford. We believe our CherryPC apps demonstrate that potential right now and have a lot of headroom for improvements to come at a very fast rate.

Use cases are a great avenue for sharing useful technical information. Please consider joining the fun! Additionally, if there’s something you’d like to see covered on the CouchDB blog, we would love to accommodate. Email us!

For more about CouchDB visit couchdb.org or follow us on Twitter at @couchdb.