(Tee11/Shutterstock)
The tech industry has a voracious appetite for the Next Big Thing. But sometimes, it’s the older thing that ends up being the right tool for a new job. That’s the argument being made by RelationalAI founder and CEO Molham Aref, who sees no reason why relational databases can’t supply the graph relationships that are helping to power a new class of AI workloads.
RelationalAI develops a knowledge graph base that’s designed to store and query connected data in support of predictive and prescriptive AI-powered workloads. In that respect, it’s similar to the underlying property graphs that store data in nodes and edges, like Neo4j, and semantic graphs like AllegroGraph, which store data in sets of semantic triples.
However, there’s one big difference between those graphs and RelationalAI’s underlying data store: the use of relational database tech and regular SQL, as opposed to super-normalized graph data structures and specialized query languages. While the leading property and semantic graphs use specialized tech, RelationalAI has built upon technology that traces its roots in the 70s. That makes RelationalAI a bit of an oddity in a hype-driven business.
But Aref makes no apologies for his approach. In fact, me made an argument at Snowflake Summit 25 last week that the relational model and SQL are the best technological foundations for building much of the data infrastructure underlying today’s generative AI and agentic AI applications.
RelationaAI CEO and Founder Malham Aref
“I think we should all just accept that the relational model always wins, and it’s going to win again here,” Aref told BigDATAwire at the Moscone Center last week. “I’m old enough to remember the 80s when people were like ‘This stuff is never going to work for OLTP. Real programmers want…flat files and navigational databases.’ And in the 90s it was MOLAP, multidimensional OLAP, is the only way and relational is stupid.”
OLAP, or online analytical processing, is still around. In fact, it’s the architectural foundation for many big analytical databases, such as Snowflake. But you don’t hear people differentiating between relational OLAP (or ROLAP) and MOLAP anymore, Aref said. Today, ROLAP basically is synonymous with OLAP.
There have been many attempts to best the relational model and SQL over the years. The whole Hadoop phase was one big experiment in that. When it was a small startup, Snowflake garnered attention by proudly proclaiming the efficiency and wisdom of using the relational model and SQL while the rest of the world was figuring out how to store data on the Hadoop Distributed File System (HDFS) and use complex frameworks like MapReduce to process it. Attempts to re-normalize the data, i.e. Apache Hive, resembled trying to put Humpty Dumpty back together again.
Aref remembers the challenge that Snowflake faced in those early days from a skeptical Sand Hill Road. He remembers former Snowflake CEO Bob Muglia telling him that Snowflake was rejected 27 times for a Series C funding round. That elucidated some chuckles from Aref as he recalled the spectacle.
“Imagine being the investor that turned down an opportunity to invest in Snowflake,” he said. “It was going to be Hadoop. Hadoop was going to be the winner. Big data was the new workload and the only way to do big data is MapReduce. ‘Look, Google is doing MapReduce. Relational is dead. Forget about it.’ And then Snowflake came up with a cloud-native architecture and came up with support for semi-structured data, and now Hadoop is COBOL.”
Hadoop is now COBOL, Relational CEO Molham Aref said (mw2st/Shutterstock)
Aref is fighting a similar battle now with knowledge graphs. Instead of moving your data into a dedicated property graph or semantic graph database, RelationalAI leaves it Snowflake tables and uses traditional SQL queries to ask graph-like questions, which can be used to feed predictive and prescriptive reasoners.
The goal is to supply data in the best possible way to feed AI algorithms, which can then reason upon it and help users get answers to tough questions, such as “What will sales be next December of iPhones in New York City”? “That is not a SQL question,” Aref said. “It’s a question about something that hasn’t happened yet. It’s not in the database.”
RelationalAI goes beyond what’s possible with retrieval-augmented generation (RAG) by training and finetuning AI algorithms on its knowledge graph using the customers’ structured, semi-structured, and unstructured data. That essentially allows the AI model to understand relationships that exist in customers’ data.
“It’s a new kind of knowledge graph,” Aref said. “It’s not a navigational graph. We’re different from graph because we can reason predictively, prescriptively with rules and with the traditional graph powers.”
Just as there are relational databases that are good at OLAP and relational databases that are good at OLTP (online transaction processing), we’re now seeing the emergence of relational databases that are good at graph workloads, Aref said.
The RelationalAI architecture
“In the end, a graph is just a connection between two things. There’s nothing about the relational model that doesn’t allow you to do to model graphs,” he said. “The beauty of the relational model is it wasn’t like hardwired for just one workload. You can do OLTP and OLAP. It was hardwired to be an abstraction, and you can implement whatever data structures and join algorithms you want under the covers.”
RelationalAI deploys as a native app within Snowflake’s platform, which brings certain advantages for the customer, particularly when it comes to the security and governance of data. RelationalAI is also adopting the new semantic views that Snowflake unveiled at Summit, which will provide more standardization and make it easier to build predictive and reasoning application on top of their data.
Aref said he respects what earlier graph database developers built using the tools and technologies that were available at the time. But thanks to advances in computing, today there’s no need to abandon the relational model and SQL to build knowledge graphs, he said.
“We’re not trying to build a cult. We’re trying to build something useful for people,” Aref said. “Our approach I think is a little bit more humble. We have more humility. It’s like, hey, you are on Snowflake. You are in SQL. We know how to make it so that you can run relational queries that are asking graphy questions.”
Related Items:
RelationalAI Debuts Powerful Knowledge Graph Coprocessor for Snowflake Users
Why Young Developers Don’t Get Knowledge Graphs
The Synergy Between Knowledge Graphs and Large Language Models