GroverDB, at its core, is a graph database, and that’s very different than a traditional relational database. So what is a graph database and why did we choose such a radical design?

Generalization Yields Flexibility

A relational database design uses an entity (table) for each logical groupings of tuples (rows: people, places, things). It follows then that each foreign key relationship between tables is a specific foreign key. For example, a relational database with about 50 tables might have 50 different foreign keys. ​

A graph database makes connections (edges) between objects (nodes). For the purposes of the connections, any object is just another object. Adding a new connection doesn’t require a new foreign key, which means that it’s much easier to add a new type of connection within a graph database is it is to add a new foreign key within a relational database. Most graph databases apply labels to nodes and connections to identify its type.

So the answer to, Why a Graph Database? is that GroverDB is designed to be highly configurable and flexible, and the graph database design is extremely flexible – much more so than the traditional relational database. GroverDB takes it a step further by adding object-oriented structure and usage rules to which classes (types) and states (statuses), because just adding a label to a node or connection is too slippery for enterprise use.