neighbourhoodie-nnh-logo

How to Sync Anything: Building a Sync Engine from Scratch — Part 2 posted Wednesday, April 16, 2025 by Jan Lehnardt CouchDBreplicationsyncdistsysdata

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

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

Read the article

How to Sync Anything: Building a Sync Engine from Scratch — Part 1 posted Wednesday, April 9, 2025 by Jan Lehnardt CouchDBreplicationsyncdistsysdata

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

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

What do I mean by that?

Read the article

How to Sync Anything posted Sunday, April 6, 2025 by James Coglan CouchDBreplicationsyncdistsysdata

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.

Read the article

How CouchDB Prevents Data Corruption: fsync posted Wednesday, February 26, 2025 by The Neighbourhoodie Team tipproductCouchDBdata

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).

Read the article

How CouchDB Prevents Data Corruption: Checksums posted Wednesday, January 22, 2025 by The Neighbourhoodie Team tipproductCouchDBdata

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.

Read the article

Resource Locking with CouchDB and Svelte posted Wednesday, January 15, 2025 by Alex tipCouchDBdata

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.

Read the article

Manual Conflict Resolution with CouchDB and Svelte posted Wednesday, December 18, 2024 by Alex tipCouchDBdata

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.

Read the article

Automatic Conflict Resolution with CouchDB and Svelte posted Wednesday, December 11, 2024 by Alex tipCouchDBdata

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
Read the article

A real-time multi-user Kanban board with CouchDB and Svelte posted Thursday, December 5, 2024 by Alex tipCouchDBdata

A Kanban Board with a number of cards, apparently used to manage various types of rodents. Two users are online, and are working on different cards.

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.

Read the article

How CouchDB Prevents Data Corruption: Append-Only Database Files posted Wednesday, September 18, 2024 by The Neighbourhoodie Team tipproductCouchDBdata

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.

Read the article

Data Format Compatibility posted Friday, August 2, 2024 by The Neighbourhoodie Team tipproductCouchDBdata

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.

Read the article

Everything You Need to Know About CouchDB Database Names posted Tuesday, October 13, 2020 by The Neighbourhoodie CouchDB Team tipCouchDBdata

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.

Read the article

An Offline-First Todo List with Svelte, PouchDB and CouchDB posted Friday, May 10, 2019 by alex tipCouchDBdata

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.

Read the article
og-image-preview