Heidi: What would a good elevator pitch for FlureeDB be?
Brian Platz (BP): Yeah. So, FlureeDB is all about bringing some of the blockchain characteristics but in a way that’s more accessible for typical applications and our focus is really on enterprise applications and what they need. We bring blockchain in kind of the familiar wrapper of a database as opposed to having to learn a completely new sort of technology, how you’re going to integrate it with your current application stack and different programming language, etc.
At the same time, we bring these blockchain capabilities, where we’ve built a very modern database. It’s a graph database, it’s got features like time travel in it, so it does a lot of things that we think people will end up wanting to use, even if they didn’t care about the blockchain aspects. They’d perhaps still even want to use it as a database.
Heidi: What scalability solutions does your system use?
BP: The way that we run it—I guess I would start out to say that the current blockchain solution don’t scale very well, especially with data, so there’s no real good data storage solutions. Our focus is on data storage, so our scalability takes it with that lens.
We run every single database as an independent blockchain and what some people would call a sidechain or a layer 2 protocol, potentially every single database ends up creating its own small economy. But they’re all tied together by a backbone chain. It’s not unlike, say Bitcoin Plus Lightening Network in our design. It’s sort of like that, where the databases run as this layer 2 protocol, but they’re still connected to the main chain. That gives us sharding right off the bat, as far as scalability relating to sharding.
Our other areas are focused on having efficient consensus so that we can process a lot of transactions in a short amount of time and that has different flavors, depending on how you’re running it. I guess the other part to this would be that it’s not a one-size-fits-all. If you’re running a blockchain across the supply chain with 20 other companies, you can favor consensus methods that take that into consideration and can be very efficient with that. If you’re running it across the—as a public blockchain and you’re running it across the globe, then you’re going to have different consensus methods and different tradeoffs. One of our keys is allowing the consensus protocol to actually adjust, depending on how you’re running it, so that when you make it efficient, it’s efficient as possible.
Heidi: What kind of unique features does FlureeDB have?
BP: Well, it’s a generic solution for building blockchain application, unlike most blockchains out there, which are very sort of purpose-suited. Every blockchain, a lot of people think of a blockchain as a database and I guess it loosely sort of is a database, but it’s a database with a predefined scheme. It can only store certain types of information in a predefined rule set.
What we have, is we allow you to create essentially a block chain as a database, where you define the data that you want to store, so it’s very flexible in that manner, and you also define the rules that run the data. If you wanted to create a FlureeDB instance that ran like Bitcoin, you could. If you wanted to create one that ran for business supply chain networks, you could. It’s very flexible in that you can use it, just like databases are used for all kinds of different applications.
That’s one key area. It’s a solution that can be applied to a lot of different problems.
Then the other big piece, obviously being a database, we focused a lot on getting data out and it is a graph database, so it allows you to run very analytical queries. Most blockchains, you can ask a handful of questions to the blockchain, as far as information, but you can run these kind of generic queries, like you can with the database. So, we allow you to get at this data in a lot of different ways, which makes it suitable to power all kinds of different applications.
One particular feature that people really love that we built, which I mentioned before, is this notion of time travel. You can query the database, which again, is a blockchain, using a graph query language. The query is for any point in time in history, so when you build the applications, you can actually build applications that can rewind the entire application to any point in time and you get instantaneous responses. Since we have the entire blockchain and usable history of everything that happened anyway, we’ve come up with ways to allow you to leverage that very quickly to build very powerful applications.
Heidi: Do you have a timetable for the full release of your platforms?
BP: Yes. We already have a beta release out. We now have about 400 companies participating in that data. Many are very large, many Fortune 500 companies, and a lot of startups, of course.
In Q2, which is now right around the corner, but probably June more specifically, we are releasing our production version of FlureeDB that can be run across multiple companies. And in Q4 of this year, we’re launching the full public version of FlureeDB, which runs sort of like a theorem, where anyone can create these public databases that anyone can mine.
Those are the next two big milestones.
Heidi: Awesome. That’s all the questions I have. Anything you’d like to add?
BP: No. I guess the only other thing that I kind of didn’t mention is that one of the things, beyond just being a database or these other pieces that I brought up, a piece that does really excite people is that we are a storage solution for blockchain applications. Most blockchains are really, really bad at storage. They weren’t designed for storage, it’s not necessarily a flaw of theirs, they just weren’t designed for it.
Yeah, definitely we like to highlight that we are a blockchain storage solution, because we really don’t think solutions exist in that space.
Heidi: Awesome. Well, thanks.
BP: Thank you.