All Data Blog Posts

CouchDB is known for JSON documents and distributed syncing. But it also handles binary attachments like images, PDFs and other files, directly in the database. This means you don’t really need an external file storage to keep your documents and relevant files together, simplifying the document management process.

One of the key aspects of CouchDB is how it handles concurrent updates. It is built for replication and offline-first or local-first use cases where multiple users and devices edit the same document independently and sync back their changes later. Instead of silently discarding a user’s changes when two users edit the same document, CouchDB keeps track of the conflicts: situations where two or more versions of a document exist simultaneously.

While other databases out there might shard, CouchDB is one of the few that does it automatically and saves you the annoying — read error-prone — work of setting it up yourself. Being unique in this way, it’s a topic you may not know too well. The arcane-sounding term (especially if it reminds you of the prismatic variety) doesn’t need to conjure confusion or intimidation. In this post, we’re going to take a deeper look at scaling CouchDB with shards: what sharding is, plus why and how to do it.

Note: This is part of our series demystifying synchronisation. See our other instalments: How to Sync Anything: Introduction and How to Sync Anything: Building a Sync Engine from Scratch — Part 1 and How to Sync Anything: Building a Sync Engine from Scratch — Part 2

Last time we learned how to efficiently decide what needs syncing. This time we will learn how to version our data.

Note: This is part of our series demystifying synchronisation. See our other instalments: How to Sync Anything: Introduction, How to Sync Anything: Building a Sync Engine from Scratch — Part 1 and How to Sync Anything: Building a Sync Engine from Scratch — Part 3

In this part, we will learn how to efficiently find out what data needs to be synchronised.

There’s an old saying I paraphrased in this by now ancient tweet[sic]:

“Friends don’t let friends build their own {CRYPTO, SYNC, DATABASE}.” — @janl on September 24th, 2014

What do I mean by that?

In this article I’ll discuss a common naive solution to replication, why it doesn’t work, and what the building blocks of a good solution look like. Having established this theoretical framework, my next article will look at how CouchDB provides many of those building blocks such that replicating from it into any other system is relatively painless.

Programming can be exciting when the underlying fundamentals you’ve been operating under suddenly come into question. Especially when it comes to safely storing data. This is a story of how the CouchDB developers had a couple of hours of excitement making sure their fundamentals were solid (and your data was safe).

CouchDB is your data’s safe place. It does everything in its power not to accidentally lose any of your data. However, sometimes circumstances are not in CouchDB’s power.

One of those circumstances is disk corruption.

This part four of our blog post series on building a real-time, multi-user Kanban board with CouchDB and Svelte. As mentioned in the previous post, UI or resource locking is one of the most promising mechanisms for avoiding conflicts in the first place: if a card is locked the moment Alice starts editing it, then Bob won’t be able to do anything with it, and therefore won’t be able to introduce a conflict. Sounds like we could have just done this first and not bothered with all the conflict handling in the previous posts! But again, it’s not quite as simple as it seems.

In our previous post, we added automatic conflict resolution to our multi-user, real-time Kanban board. This would silently resolve any conflicts where two users simultaneously modified two different properties of the same Kanban board card, eg. Alice changes the card’s title, and Bob changes the card’s location. While these changes constitute a conflict on a single database record, they don’t actually collide within that record, and thus the conflict can be resolved by a machine.

Regrettably, this doesn’t solve all possible conflicts: two users can still simultaneously modify the same property of the same card, eg. both Alice and Bob edit a card’s title.

This is the second part of a blog post series on building a real-time, multi-user Kanban board with CouchDB and Svelte. We’ve previously made design decisions that should help reduce the opportunities for conflicts, but since we can’t rule them out completely, we do need to provide ways to resolve them. In this post, we’ll be covering the possibilities of automatic conflict resolution, which means:

• A machine can resolve the conflict without any user input
• The resolution happens in the background without anyone even noticing

In this first post of a four-part series, we’ll start building a real-time Kanban board, and discuss the challenges and trade-offs.

CouchDB takes keeping your safe very seriously. It does everything in its power not to accidentally lose any of your data. Let’s look at one of the things that keep your data safe: append-only database files.

When storing data in CouchDB, you send JSON in one form or another. When you retrieve data from CouchDB it is also in the JSON format.

Naming a database does not sound like an exciting activity. But it can be, if you know all the considerations that go into naming a database in CouchDB. Let’s start with the restrictions.

Today, we’re combining Svelte, the lean and fast frontend compiler, with PouchDB and CouchDB, and building a lightweight, Offline-First todo list app. It’ll sync your todos between multiple devices for offline use and also keep your data in a central backup database.