“FlureeDB is a database purpose-built to fit the requirements of modern enterprise applications while providing blockchain capabilities for data security, workflow efficiency, and industry interoperability.”
Sound intriguing? I thought the same, and if the team behind Fluree delivers everything it’s promising, the results could be staggering.
To find out more about Fluree, I spoke with its Co-CEO, Brian Platz. Hear the full interview below.
For over two decades, Brian Platz and Flip Filipowski have been building software companies together. They oversaw two IPOs — one of which involved the 8th largest company in the world — and have secured the largest cash sale of a software company ever. Suffice it to say; they have experience working with software.
Fluree is Brian and Flip’s latest project, conceived just over four years ago. It’s a new type of data platform for modern apps, and they created it because they frequently found themselves struggling with database limitations.
Brian and Flip felt that while software and software delivery (think SaaS) has moved in leaps and bounds over the years, the DBs that underpin software haven’t evolved — despite the increased importance of data.
One of Fluree’s most significant differentiating factors is that it decouples the processes involved with updating data and querying it. Furthermore, a blockchain records every single DB change ever made, allowing for limitless querying of a potentially infinite number of versions.
Fluree has the concept of “Fuel,” which is similar to Ethereum Gas and is calculated based on every DB query that’s performed, as well as the three current Fluree interfaces: GraphQL, FlureeQL (a JSON query interface), and SPARQL.
Fluree released a licensed version last December and, so far, early adopters have tended to be other tech start-ups — blockchain-based apps that are using Fluree as the foundational pinning. That’s because, with Fluree, you can write custom blockchain logic without having to fork another blockchain, i.e., you can get your project off the ground in a significantly shorter space of time.
Two such early adopters are IdeaBlock — which is looking to disrupt the digital patent system — and Fabric — which is challenging the traditional advertiser ecosystem and looking to help people monetize their data (rather than having it sold by the likes of Facebook).
Brian also mentions that the biggest beacon on the 6-month Fluree roadmap is that it will be fully open sourcing this quarter. It’s APIs are stabilized and good to go.
All in all, there’s no question that Fluree is jam-packed with features and heaps of potential, let’s take it for a test drive.
Then run the following command to start a Fluree instance:
Once started, Fluree runs on port 8080 and has a GUI and REST endpoints for most operations you need.
After installing and starting, I followed the “ Examples “ section of the documentation, that walks you through creating a cryptocurrency. With Fluree, you always have the choice of using FlureeQL, GraphQL, SparQL, or curl. For example, to create a schema with curl, use the commands below:
-H “Content-Type: application/json”
-H “Authorization: Bearer $FLUREE_TOKEN”
The authorization token is one of the interesting parts of Fluree, as it is tied to a keypair, something familiar to any Blockchain users. Read the documentation for more details, but I used
./fluree_start.sh :keygen to get me started with an autogenerated pair and user id, and derived a token from that.
You might have noticed that Fluree is not a NoSQL or schemaless database, which means that you need to cope with schema changes, I couldn’t find any official mention in the documentation on any specific functionality on how to handle these changes.
Next, you add sample data, again with the four methods available to you. As Fluree is a somewhat relational database, you can add “relations” using what Fluree calls “predicates.” Fluree also bundles a set of predicate types to define what data type the relationship is, or you can use functions to define the predicate, which is where Fluree gets interesting. For instance, with the Cryptocurrency example from the docs, you can define predicates that are somewhat like Solidity (the Ethereum smart contract language) functions, for checking balances or protecting against double spends.
Fluree is fascinating, but the multitude of bundled features overwhelming, sometimes too much choice can be a little daunting and confusing. It’s kind of like a database engine, plus a semblance of an application layer bundle into one. I know that many older, relational databases have packed these sorts of features in the past, but it’s been a while since I have used a relational database, and have got used to the simplicity of NoSQL offerings. The different interface options are welcome, but I wonder if maybe picking and sticking to one might have been a better engineering decision, especially FlureeQL, which is unique to Fluree. Adding “blockchain” to the tech stack is a choice I am unsure about. I covered BigchainDB before, which attempted to do the same, albeit in a different way. I’m unsure if Fluree’s blockchain features comprise and actual blockchain, or just blockchain-like features, but that’s fine, if you have a use case for them, it doesn’t matter what you call them.
I was also unable to test anything like performance or reliability metrics of Fluree thoroughly, so whether all the features add much overhead I’m unsure. All in all, I strongly suggest you test Fluree and see how it may work for your application use case.