This week, we shared some big news to the Source Network developer community — and everyone who shares our vision of a truly democratized and decentralized future for data management. DefraDB v0.6 is officially released! While devs or some of our more technically-minded readers can (and should!) check out all of the key changes, features, and fixes on our Github, we wanted to expand more on what's new (and coming) via DefraDB's latest pre-production release.

Who better to help educate on the latest and greatest version of DeraDB than our brilliant lead dev for the database, Fred Carle? Below, read a Q&A where we dig into what goes into a pre-release update, the most pertinent feature upgrades, and how DefraDB v0.6 is empowering developers with the most flexible and innovative tools for decentralized data management.

Read an introduction to DefraDB on our blog

Source Network: Fred, tell us a bit about what goes into pre-release updates and what you’ve been working on before DefraDB 1.0.

Fred Carle: The goal for these pre-release updates is to reach a certain level of stability and features. — we’re building a solid foundation. Users should expect that once we reach version 1, the subsequent updates will keep stability of the features, meaning there shouldn’t be any breaking changes over that version until we reach version two. What you can expect though for version 1.1, 1.2, and so on, is the addition of even more features, tooling and continuous polishing of the existing code base. Before that point, we're not too concerned with potentially breaking some functionalities. As we go along with pre-releases, we try to collect as much feedback as possible from our early adopters. We might discover that a certain feature (or how a user interacts with it) needs to be changed for various reasons.

What’s changed since the first version? And what are some of the key updates for v0.6?

The way the database was initially designed, you've got the way the data is stored, the way you visualize it, and how we have the commit history (history of change) so that you can audit your data. That's all core technology that’s been designed since the database's inception. But now we're adding all the features for usability around that. So, the way the users are going to interact with it. A lot of those features didn't even exist initially. Version 0.6 brings more capabilities and features to interact with the core tech.

How does this pre-release stage differ from a traditional testnet?

Testnets are usually associated with pre-release trials of protocols to get some feedback from users and test the system, including security.

Though the SourceHub protocol isn’t quite ready for a testnet as we are finalizing its integration with DefraDB, in the meantime, we released DefraDB first to gather feedback from early adopters and prioritize features.

The core product, which is the database, can be used in some aspects separate from the protocol at this stage. Though obviously, the protocol is still an important part of the whole system. We are currently getting people to use DefraDB and integrate it into their applications without using the protocol. And we have a bunch of partners doing just that. The testnet is right around the corner, pretty much as soon as the protocol is integrated, which means the full Source Network stack will then be available for developers to use.

What do people seem to be reacting to the most (or best) so far?

Two things are quite surprising at this stage of development. The number one is the speed. Our partners are impressed with how fast the database is, especially for how we store our data, keep track of all the historic changes, and have audit capabilities. The other thing is the simplicity with which you can build queries and get all the information you want, without manually building those objects returned by the database.

If you're familiar with SQL, or any SQL-type database, you often have to join different tables. Say we're trying to join two tables — i.e., getting users and their addresses. So the SQL database will return a bunch of rows, and will duplicate the user for every instance of an address that exists for them. And then, you need to assemble that object into something that's one user with all its addresses.

And that's just a simple one-to-many relationship you're trying to get. Imagine trying to build a really complex object, like a social network, where you're trying to load the page and the user and then their profile image, friends, or a community they're subscribed to. It becomes really complicated to assemble these objects in a meaningful way for the application that's consuming them. How we build our queries in DefraDB and how we return them makes it intuitive for users. They can build really complex queries, and the objects will be returned as expected and represented by the query. And it's all ready to be consumed by the application.

What are some of the other key upgrades of 0.6?

We now have the migration engine with LensVM. This enables a certain complexity of change with migrations. You can create migrations that are just a change of what the data represents without changing the schema itself. You can also even change the schema and do some computations on that data.

Can you expand on that?

If you're trying to do some kind of migration, you have to change the schema, and then separately, you have to code the change to the data. It's two different processes — one where you're interacting with the database and another where you're interacting with the software interacting with the dataset itself. With Lens, we enable doing that within one system and operation.

You also mentioned a developer playground. Tell us more. Sounds fun.

The playground is a really nice feature for users who want to just play around with different things without having to build an app first. You can browse and interact with the data and collections in an intuitive and visual process.

Looking to v1, what are you most excited to deploy?

A big one coming for this next release, which won't be v1 just yet, but the release coming out seven weeks from now is that we're starting to integrate ACP (Access Control Policy) into DefraDB. Right now, no authentication is happening — and, when you have a database, you need the security of authentication.

Since it's developed separately, we have the protocol team working on all aspects of authentication and authorization. Integrating the ACP is an important step in bringing in the protocol. This is going to be pretty massive. We’ll also have more advanced CRDT types, enabling more resilience when having multiple updates across different nodes and having to merge that data. It will make a big change in audits and data validation.

Learn more about DefraDB on our website (and GitHub) and head to our Discord to chat more about the update — and beyond. Follow Fred on Twitter!

— Source Network