If you’ve ever dabbled in coding, you’ve likely heard of something called a “relational database.” If not, bear with me.

Traditional relational databases are like spreadsheets. Different spreadsheets, each holding a specific kind of data, account for all of the information critical to a business, organization, or individual. To call on this data, unique ID numbers are associated with specific cells within each spreadsheet. When you want to reference data, you create a program that requests whatever information is available for a specific ID in a specific spreadsheet.

To track their products, a business might use multiple databases: one that houses all of their customer names, one that houses all orders, one that houses available customer service call centers, one that houses upgrade options. In a standard relational database model, a single ID would point to a customer name in one database, a product they purchased in another database, and their local customer service call center in a third database. If a software program needed to call on any of this information, they could reference an ID number and a specific database. Something like this: “Hey database, give me all orders for ID 859485.”

Here’s the problem: Not only do systems need to call on multiple databases for a complex string of information (each piece of data requires a separate request), but there’s no clarity on how the various pieces of data are related. The interdependence or hierarchy of information is lost. A more complicated request, like: “Hey database, give me all customers who purchased orders for a widget and then upgraded after December of last year without having called customer service.” would cause traditional relational databases to implode. GraphDB (aka graph database) to the rescue. This nascent approach to data management not only leverages grouped data storage, but folds in details about how various data points relate to one another.

There’s an example of Lemonade, a tech-minded startup that has disrupted the rental insurance market with low prices, a program for donating premium surplus money to charity, and a Better-Than-Human customer-facing conversational AI. They are using it right now via Jim, their claims bot. “Jim’s AI tracks loads of user-generated data-points to help us identify suspicious activity and predict what our customers need before they even know it. In the first month or so, our system tracked 3.7 million signals.” There is one more example of the fraud protection practical example where a bot detects suspicious activity on a credit card.

Tweeting proudly about the specifics of Jim’s fraudulent claim detection methods put Lemonade in a pickle earlier this year. While the controversy around the fairness of the data mining practices didn’t appear to slow their momentum (they have products available in every state and are branching beyond selling renter’s insurance), it’s worth remembering that these hyperdisruptions can have massive impact and will come so quickly that it will be hard to reconcile many of the moral quandaries they poses in real time.

Our widget company above might want to know which upgrade options are available to customers based on the widgets they’ve already purchased. In order to call on the right database information, the specifics of past orders for a specific customer need to be referenced. A graphDB treatment of this dependence would look something like this: “Hey databases, find me all customers who have purchased widgets in the last 30 days but have not yet purchased an upgrade. Then, show me what upgrades they’re eligible for based on the widgets they bought.”

The hierarchy and dependencies here would need to be manually handled with traditional relational databases. With graphDB, however, built-in relationships become the key to unlocking meaningful, actionable information via simple requests.