Sometimes your data needs to go beyond what a single instance of a database can handle. And that is when you start thinking about growing and scaling your data storage. Usually the common practice is to grow into a distributed approach.

However, today we’re going to be seeing a slightly different alternative: decentralized databases.

Have you heard of them? The term “decentralized” is definitely in everyone’s mouths these days thanks to blockchain-based technologies. But what does it really mean, especially for a database?

Let’s dive right into it!

Decentralized vs Distributed

Let’s first address the pink elephant in the room. Because the main reason I’m writing this article is the fact that these two terms might seem like the same thing, but they’re definitely not.

They both do refer to the fact that you’ll be dealing with multiple servers, and most likely they’ll be located in different physical locations. But that’s where the similarities end.

While the distributed approach will effectively split the data and the processing of that data (queries, data wrangling, and so on) amongst many nodes of the cluster. It does so because every node knows and trusts each other. They either have an internal list of cluster nodes (sort of like a Redis cluster) or they rely on a single (or few) central authority to keep track of that information (like a Hadoop cluster does).

Decentralized networks of nodes share data with each other, but they do so without knowing who’s on the other side. They can achieve this because of the underlying technology that powers these clusters. The implementation might change, but essentially what is known as “Byzantine Fault Tolerance” allows the network to remain consistent and secure even if one or more nodes are compromised (i.e taken down, hacked, etc).

The other major difference, and usually one of the main reasons why you’d pick one over the other, is that distributed networks are owned by a single authority (i.e your cluster can reside on AWS for example, and they own that infrastructure) while decentralized networks have no single owner.

And while that might seem scary, considering that one of the advantages of single authority is that you as a client know exactly who to blame if things don’t work out, the decentralized approach underlying tech prevents those catastrophic scenarios from even happening.

Thus removing the dependency of an entire network of nodes of a single entity. This can be a major deciding factor depending on your business needs, so it’s important to keep this in mind when deciding on decentralized vs distributed approaches.

A decentralized database

With that out of the way, why would you choose a decentralized database?

As I mentioned before, I think the biggest decision driver here would be your business requirements but let’s dive into some of the characteristics that might tip the needle in one direction or the other.

• Data replication: a decentralized database will duplicate your data across the network. While there might be variations on specific implementations, the general consensus is that each node of the network will hold your entire database. This is great because by distributing the nodes across the globe, you can achieve very low latency serving clients with the fastest node.
• Data security: mind you, this “security” doesn’t refer to the access control features you might be thinking of, but rather to the fact that decentralized systems have an intrinsic “vetting”. This particular feature will ensure that every time new information is entered into a node, the rest of the network will vet it before it can be distributed across all other nodes. This ensures that if a node gets compromised somehow, the information, on a global scale, won’t be affected. Essentially removing a big chunk of common security vulnerabilities associated with distributed systems.
• Global stability: this type of architecture is considerably less error-prone than a distributed system. In the latter you usually have architectures that rely on a single authority for certain tasks, turning that entity into a single point of failure (i.e if that fails, the entire cluster is rendered unusable). Of course, many high-end solutions try to provide solutions or alternatives to this problem, but with decentralized networks, you don’t really have it to begin with. This is because there is no central entity doing anything, everything is done by everyone (or at least, the majority) making it very hard to knock down one of these databases.

Granted, you might not require such characteristics, or maybe you’d rather trust a single company to hold your data and remain active no matter what. After all, that is what we’ve been doing so far, and it’s worked out quite fine, hasn’t it?

But if you’re not in that category, if you’re building something that you don’t want others to control or censor. If you don’t really trust a single company to remain open and neutral regarding the type of information you use. In that case, perhaps a decentralized approach is perfect for you.

What are the options?

While the decentralized paradigm might seem quite appealing to you, it’s also important to remember that it has only recently started to grow fast enough to trigger the creation of new projects and technologies around it.

That is to say, many of these solutions are quite new and while they do work, you’d be smart to do some research before deciding on one of them.

BigchainDB

BigchainDB attempts to mix both the blockchain world with the database world, providing a decentralized solution for your data storage and retrieval needs. It was first released in 2016 and it’s been evolving since then, which means it should be a solid alternative. Mind you, MySQL has been around since 1995, so relatively speaking Bigchain is like a toddler database, but still, within the decentralized movement it’s definitely a good option.

If you want to know more about BigchainDB they even published the whitepaper this database is based on, so you can read it yourself.

HarperDB

HarperDB offers a very interesting approach to hybrid storage, which allows you to have an edge-cloud setup where your remote devices only care about sending local queries while the database itself takes care of synchronizing its content with the rest of the cluster.

Through their table-level pubsub mechanism, you’re able to sync single tables across the globe, while your local devices maintain millisecond-level latency to the data they need.

CovenantSQL

As I mentioned before, some alternatives are new, and while they might seem interesting it’s your responsibility to understand if they’re ready for your use case. ConvenantSQL is one of those examples.

Their premise is to have a decentralized, SQL-based database that you can use for whatever you want. They advertise themselves as an open-source alternative to AWS’s QLDB (Quantum Ledger Data Base).

That sounds amazing, but they’re on version 0.8, which leads me to believe, they’re good, but they still have some more work to do to truly be an alternative to AWS’ option.

Are you using a decentralized database for your application? Or are you still relying on the good old (and trusted) distributed approach to growing your storage and processing capabilities?

Share your experience in the comments, and if you know of a different decentralized database that is worth mentioning, add it in the comments so everyone can know about it!

Build composable web applications

Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.

Bring your team to Bit Cloud to host and collaborate on components together, and speed up, scale, and standardize development as a team. Try composable frontends with a Design System or Micro Frontends, or explore the composable backend with serverside components.

Give it a try →