Deprecating fullfatdb

If you run a replicated copy of the registry database, you should read this. If you don’t know what couch replication is, you can ignore this safely. This post is only of interest to a few advanced users.

When we first talked about our new architecture back in January, we talked about splitting off the binary attachments from the main Couch database, and keeping only metadata. We called this new database “skimdb” (as in skim milk). At the same time, we kept a database in the old format available so that users who were replicating from the previous database could continue to do so without interruption. We called this “fullfatdb” (geddit?).

We thought having attachments out of the database would make running couch in production more manageable. That has proven to be the case, and has shown up as significantly improved registry uptime, though we continue to work on improving it further.

We hoped that external users replicating from the old-style fullfatdb would transition to replicating from the public skimdb registry for the same reason we did – it’s easier and faster. Lots of them have, but not all of them.

In the meantime, fullfatdb has continued to grow in size and become harder to manage. We’re now spending an inordinate amount of time maintaining fullfat, to the benefit of only a very small handful of users. That time could be better spent creating new features and improving our service for the benefit of the rest of our users.

With this in mind, we’ve made the decision to deprecate the fullfatdb service, effective today. We will keep it fully up and running for 3 months, and after that it will be shut down.

If you don’t need a database with attachments, do nothing. Skimdb isn’t going anywhere, and will continue to be available for public replication for the foreseeable future.

If you still need a database with attachments, don’t worry. We have created and open-sourced npm-fullfat-registry. This is exactly the software that we run internally to produce the full-fat registry. It works by replicating from the public skimdb and our binary store. If you run this software, you will get a copy of fullfatdb, exactly the same as the one you have now, but via the changes feed instead of replication.

We’re aware that deprecating an existing service creates work for downstream users, so we don’t do this on a whim. If this move creates significant problems for you, get in touch and we’ll work together to minimize the impact.