In the world of data management, two distinct paradigms emerge: the long-standing reliability of relational databases and the emerging power of event-native databases.
These distinct models offer unique approaches to handling data, but what sets them apart? How can they synergize to help you get more from your data? Let’s explore.
With their roots dating back to the 1970s, relational databases hinge on the fundamental principles of the relational data model — a conceptual framework designed to organize and structure data in a logical manner.
Within relational databases, data is organized into tables with predefined schemas, supporting structured data storage, transaction processing, and complex querying through SQL. The vast amount of effort and research that’s gone into relational databases mean they have been widely adopted and are the backbone of many existing enterprise systems.
In today’s data driven world, one of the biggest challenges with relational databases is around intentional data loss architecture. Relational databases store current state; when a row is updated or deleted, that data is thrown away, taking with it your data integrity and insight around what exactly happened.
Moreover, whilst these databases are good at querying certain shapes of data, other shapes - such as data that is naturally a graph - might benefit from another type of database for querying e.g. a graph database.
While relational databases provide a general technology for both reading and writing, they aren't highly optimized for either task. As data gets normalized and split into multiple tables, write transactions can span many tables and queries will often require a large number of joins to read the data. This has led to the development of more query-oriented analytics databases to compensate for these limitations.
This emerging database category uses an event-native data model. To leverage this data model, key features include streaming, transformation (projections), subscriptions, and replay. Natively focused on storing events as an immutable sequence, event-native databases like EventStoreDB keep the order and business context of any state changes. Whilst events in the log cannot be changed, their impacts can be altered by later events.
Event-native databases take advantage of the economic trends in modern storage costs to make it feasible to store every state change along with its business context. The state change is the most fundamental approach to data storage, which can subsequently be “projected” into other existing data models such as relational, graph, or document.
Event-native databases concentrate on capturing data at its most elemental level and projecting (transforming and streaming) it into the shape required by downstream systems or technologies.
Note that not just the data that is changed is kept in the data model; this data is “wrapped” in the business context, denoted by the term “event”. For example, say a customer’s last name was changed from “Jones” to “Smith”. That could be a:
This context could prove vital for consumers of this data (for example, an AI algorithm). While the application is aware of this context when data is written, no other data model that we're aware of stores it as a first class part of the data model.
The capability to replay events and project them into new forms as requirements evolve and novel data technologies surface is a standout feature of event-native databases.
To illustrate how this works in practice, imagine an “InvoiceIssued” event is appended to the log one day, only the address the invoice was issued to was incorrect. In traditional databases, the old address would likely be overwritten. But in your event-native database:
For each event, the dates and times will also be stored. You can even store who made any changes to your data (e.g. customer or agent), allowing you to go back in time to understand what occurred. You’ll therefore retain the business context - a wealth of information that's often lost in traditional databases.
Given the differences in the fundamental data models and design principles of event-native and relational databases, the former is increasingly suitable for modern microservices operational workload while relational databases leverage their strong query capabilities.
The event-native database is designed to store data at a more elemental level and stream it to the query technology most suited to your specific requirements. This could be relational, graph, document databases, or any of the cutting-edge advanced analytics - especially machine learning and artificial intelligence technologies. Importantly, thanks to its data model and replay capability, data can be replayed as requirements change or new technologies emerge.
Relational databases are unparalleled in their query flexibility and user-friendliness. Millions of developers and business analysts utilize SQL in their daily operations and applications.
Event-native databases and relational databases are complementary when used together. The event-native database can be used to keep data at its most fundamental level and then stream in real time to a relational database. With this model, the data in the relational database can be optimized for query since the initial write happens in the event-native database. This allows the best of both worlds:
Of course, when this approach is used the potential to use other query technologies in addition to relational is also available.
Learn more about EventStoreDB - an operational database that uses the event-native model - in our webinar: Why EventStoreDB? Simplified.