At Relational AI, we have built the first Relational Knowledge Graph System
(RKGS).

We believe relational knowledge graphs are the foundation for data-centric
applications - these are systems that learn, reason, and predict over richly
interconnected data.

Why Relational?

In some of our other posts we discuss where we are today and where we will be in
the future. In this post we look at the historical trends that we have witnessed
that support our belief in the Relational paradigm and that a relational
knowledge graph management system is history repeating itself . . . again!

Let’s revisit this history and trends. It’s been said often that data is growing
in velocity, variety, and veracity; starting with structured, adding semi
structured, and most recently complex (unstructured for SQL). But this data
growth is part of the back story.

We see everytime that data has hit a growth spurt (volume) or new types have
arisen (variety), the data model and approach to handle it has left relational
faltering and a new temporary paradigm comes along.

However, once the relational paradigm catches up, it replaces these temporary
workarounds and creates new multi-Billion dollar industries.

The relational paradigm always wins.

It wins because it separates the WHAT from the HOW. And it wins when the hard
parts that the patch solutions work around become part of the relational
paradigm.

WHY? Because of the following features:

• Automatic query optimization: Cost estimation for operator ordering, join
  algorithm, join order and index/data-structure selection
• Automatic memory management: Garbage collection & Out of core support
• Automatic parallelization & acceleration: Vectorization and compilation.
  Shared memory, distributed shared memory, shared storage, shared nothing.
  Multi-core, GPU
• Automatic transaction management: Atomic, Concurrent, Isolated, Durable (ACID)
  guarantees
• Automatic incrementalization, liveness, and streaming

WHEN these hard parts become part of the relational paradigm!

• New data structures (e.g. columnar storage, bitmap indices, semi-structured
  data)
• Query evaluation algorithms (e.g. parallel joins)
• Query optimization technology (e.g. cost-based optimizers)
• Query language innovations (e.g. stored procedures, recursive queries,
  materialized views)

For example, the Map-reduce and NoSQL movements emerged because relational
systems couldn’t hack the new “web-scale” workloads. Control had to be given
back to the programmer in order to get “web-scale” performance and scalability.
This control came at a big cost. But when cloud-based DW systems showed they
could operate at “web-scale” and still deliver the benefits of SQL and near
zero-management of a hosted solution, then relational reasserted itself as the
paradigm preferred by business.

The most important motivation for the research work that resulted in the
relational model was the objective of providing a sharp and clear boundary
between the logical and physical aspects of database management. - >
E. F. Codd

You get to take advantage of all the investment (time/money) that has gone into
the relational paradigm, which is considerable and impactful, and delivers
efficiency and scale.

We believe that Relational Knowledge Graphs are the foundation of modern Data
Apps and Machine Learning.

And we believe the relational paradigm will win again.

This time, not only has the Relational technology caught up, but the underlying
relational math is a natural fit for machine learning (ML) algorithms. It
finally makes sense to build the ML directly into the relational database and to
eliminate hybrid ML/SQL approaches.

Thank you for reading this post on the history of relational paradigm. If you
would like to learn more, Contact Us.