This is a guest blogpost by Luca Olivari, president, ArangoDB.
Data is one of today’s biggest assets but organizations need the right tools to manage it. That’s why, during the last decade, we’ve seen new data-management technologies emerging and getting past the initial hype. The so-called “big data” products, Hadoop and its surrounding ecosystem first and NoSQL immediately thereafter, promised to help developers to go to market faster, administrators to reduce operational overhead and devote less time to repetitive tasks and ultimately companies to innovate faster.
The need for change
One could argue there’s been some success, but the craving for new and different approaches has given birth to hundreds of products all addressing a specific niche. Key value stores are blazingly fast with extremely simple data, document stores are brilliant for complex data and graph solutions shine with highly interconnected data.
Every product solves a part of the problem in modern applications. But besides having a steep learning curve (in truth, many steep learning curves), keeping your data consistent, your application fault-tolerant and your architecture lean is rather impossible.
Teams were forced to adopt way too many technologies resulting in the same issues faced at first: complexity and inelasticity. NoSQL companies realized they were narrowing their use cases too much, and started to add new features in the direction of relational data models.
Relational incumbents reacted and vendors added document-based or graph-based structures and features, removing schemas and generally trying to mimic the characteristics that made NoSQL successful at first, and semi-successful at last.
Relational databases have been so successful for one main reason: broad applicability and adaptability. All developers on earth know relational and it comes to mind as the first underlying data-management technology when building something new, regardless of the application itself… True, relational are almost good for everything, but they never excel.
There’s something wrong with two worlds colliding
Of course, you can take a petrol car, find a way to put a battery plus electric motor in and call it an electric car. You’ll end up with low range, low performance and no users. The huge success of Tesla is by design. A Tesla is superior because it is designed from scratch for e-mobility.
The reality is, the underlying architecture is so important that something that’s not built from the ground up, will never be as effective as a product conceived with the end in mind. Exponential innovations are architected in a different way and that’s why they are disruptive.
This is happening in the database world as well. There’s a new category of products that’s solving old issues in a completely different way.
Native multi-model databases
Native multi-model databases, like my own company’s ArangoDB, are built to process data in different shapes: key/value pairs, documents and graphs. They allow developers to naturally use all of them with a simple query language that feels like coding. That’s one language to learn, one core to know and operate, one product to support, thus an easier life for everyone.
Let’s quantify the benefits for a fictitious Fortune 500 customer. When you have an army of tens of thousands of developers and so many different on-premise or cloud based databases to administer, even a small improvement in productivity means a lot. An approach like ours allows you to build more things with fewer things and simplify your stack in the process. You could say the mission is to improve the productivity of every developer on earth.