Database construction is a fundamental part of data management— and there are multiple options for developers to choose from and implement into their toolkit, depending on the use cases they are building for.
In this explainer, we’ll be talking about NoSQL databases and document stores (with a nod to SQL databases, which are key to understanding if you want to know what else is out there and why). By the time you’ve reached the end of this article, you should understand what a NoSQL Database is, how we leverage this technology at Source Network for our own decentralized, peer-to-peer NoSQL database — DefraDB — and why we think it’s an essential piece of technology for you to understand as someone potentially interested in using DefraDB to manage data for your application.
NoSQL vs SQL Databases — What’s the Difference
Unlike SQL (Search Query Language) databases, which are relational, meaning data is stored in tables and organized into rows and columns similar to Excel, NoSQL databases are used to describe non-relational data systems. NoSQL (Not Only SQL or Non SQL, depending who you ask) databases are predominantly designed to handle unstructured and semi-structured data, another key differentiator from SQL databases.
An additional difference between SQL and NoSQL technology is what’s required to add more data to a particular database. In SQL databases, adding a data table tied back to the original table requires an ID — and if you want to access data from one table, you must access multiple tables simultaneously, which requires scaling, and vertical scaling at that. Vertical scaling requires more storage, computing, and memory, which can prove difficult and limiting when managing data in web-scale applications, and especially within web3 products and use cases.
Unlike the related tables of SQL databases, NoSQL databases don’t require data stored in associated tables (occasionally clunky and constrained), which scale vertically. NoSQL databases provide more flexible storage and data-model and schema options, such as key-value, graph-based, wide-column, column-based, and document-based.
SQL Databases — Tradeoffs
While SQL databases have familiar, organizational benefits, their relational nature can cause friction — such as the need to reference schemas by an individual ID — which requires multiple inner joins to map foreign keys to specific scheme tables. Each step must be written as a manual query, which can become an arduous task for developers. With NoSQL and document stores, however, it’s much easier to query data relations whichever way you please — another lack of customization often associated with SQL databases.
NoSQL Databases — Benefits
So, what’s so great about NoSQL databases, and why have we modeled our database, DefraDB, after this technology? Much of this design choice boils down to flexibility — i.e., the types of document stores capable. NoSQL databases store data in a wider variety of formats: structured (tables), semi-structured (documents and graphs), and even unstructured data like images, videos, and social media posts. These storage capabilities make NoSQL databases excellent for handling off-chain data for NFTs, Oracles, Indexers, DeFi, DeSo, and many other environments where applications require dynamic, rapidly evolving data structures.
Additionally, due to its ability to easily add more peer-to-peer nodes (i.e., spread data across as many nodes as we want to compensate for the limitations of a single node) between the database and application data, DefraDB gains the added benefit of nearly infinite horizontal scale, a key differentiator from traditional NoSQL databases like MongoDB and added benefit for companies looking to grow their products.
NoSQL & DefraDB in Action: A Schema Walkthrough
Ok, now that you have learned more about the differences, benefits, and tradeoffs, of SQL and NoSQL databases, let's walk through an example of how a simple music sharing application could be built using both an SQL database and DefraDB. If you’re wondering why we would present both examples, our intention is to show some of the limitations of SQL databases in hopes of demonstrating how NoSQL databases — and more specifically, decentralized NoSQL databases like DefraDB — create solutions to these limitations. Let’s get into it.
The theoretical music application will have three schema types: Artists, Songs, and Albums. Songs are created by an Artist and belong to an Album.
The SQL schema requires us to manually define the relationships using foreign key constraints and primary key fields.
The DefraDB schema allows us to simply reference the schema types directly when creating relationships. Note that the relationship must be defined on both sides. An added benefit is that we can query the relationship from either side.
Now that we have the schemas defined, let's write a query that gives us all of the song and album titles for an artist. For demonstration purposes, we’ll be using the artist Prince (and because he’s incredible).
The SQL query requires multiple inner joins to map the foreign keys to their respective schema tables. Note: joins are tricky and make queries more difficult to understand.
A similar query using DefraDB is much simpler and more expressive. We can access the relationships and their fields directly from the document.
Now for the fun part. Let's make our music-sharing application collaborative.
If you are building your application with an SQL database, you will have to create your own backend servers and network protocols for sharing data.
With DefraDB, all of the complicated networking is handled for you. Simply connect two or more DefraDB nodes, and all of your data will be synchronized. Voilà!
How Source & DefraDB Leverage NoSQL Databases — and Why
As Source Network is focused on empowering web3 developers to build the next generation of applications — and manage their data in a decentralized manner — flexibility and the ability to synchronously manage data across dynamic environments is key.
To store (and manage) data across these kinds of next-generation industries and dynamic use cases, next-generation NoSQL databases like DefraDB reimagine schema management to compose a semantic web of data instead of schemas enforcing an arbitrary syntactic structure.
This ability makes it easier and more intuitive for developers to adapt to fluctuating data requirements without having to modify the structure of their database, which causes friction and takes time. In the case of our music application example, semantically linked data means that you don’t need to know what the schema structure looks like because it’s entirely self-defining. So, when you go to query data, you know immediately what the format looks like (whereas in SQL databases, everything is defined ahead of time in tables, which is more of a rigid approach).
All in all, as outlined in the example above, DefraDB extracts the most efficient and intuitive elements of historical database approaches (SQL, standard NoSQL, etc) to offer developers a delightful and frictionless schema management process you can't get anywhere else.
If you’re ready to connect DefraDB to your application to manage your application’s data — and scale your product — contact us on our website.
Explore our GitHub and developer portal for additional documentation on our technology.
Thanks for reading!
— Source Network