A Graph Database Management System (DBMS) is a database system optimised for managing highly-related data. An obvious example is the Facebook social network of people and their activities. But relationships between things are a key part of any data management - and the more data we store, the greater the number and nature of relationships we need to make sense of.

"But isn't that what Relational Databases like Oracle and MySQL are for?" you might ask. The truth is that these products aren't relational stores at all - they're a collection of flat tables with a relational query language (SQL) tacked on. So when it comes to working with highly-related data, a Graph DBMS can be thousands of times faster.


What's more, the Relational DBMS puts a straight-jacket over your database. You need to create a "schema" to define your data and its relationships and that schema makes it impossible to adapt to your changing data needs without complete re-engineering.

There is a better way. A good Graph DBMS is a faster, more flexible and future-proof way to manage more data. Traditionally, however, Graph Database implimentations have had problems that limit their usefulness...

  • Storing data in a graph can be slower than other forms of database storage. This makes them less-suited to high-throughput and transaction-processing tasks.
  • They can impose unnecessary structural complexity. Sometimes simpler structures are easier to manage and provide better performance.
  • They're difficult to query. Generally the tools available for working with a Graph DBMS are poor.
  • Their flexibility provides too much freedom for Enterprise data stores with tight rules and many different uses.

GraphBase is the first Graph DBMS to properly address each of these issues with its graph-focused query and transaction models, its rich tool set, its support for hybrid data stores, and its many other Enterprise-focused features.

You Should Use A Graph DBMS If...

  • You're not sure what the medium-term needs of your data store will be. A Graph DBMS will allow you to be agile.
  • You have multiple redundant data stores and applications that can't talk to each other. A good Graph DBMS has the flexibility to intermediate between applications and to be your store of "Master data".
  • You're facing a data migration that's going to cost tens of thousands of dollars or tie up resources for many months. With a properly-implimented Graph store you'll never have to migrate again.
  • You're looking to create something new. A graph DBMS may be the only way it's possible.


On a more technical note, you should consider a Graph DBMS if...

  • Your RDBMS schema is bigger than a white board.
  • You've denormalised your schema so much that the redundancy makes you uncomfortable.
  • You find yourself creating materialized views or other intermediate data structures just so you can get adequate performance.

When NOT to use a Graph DBMS

  • If you know the job can be done with a Relational Database, then that's what you should use. It's a well-understood, conservative technology that will give you more choices, more tools, and more resources.
  • If your needs are for simple data collection and retrieval at high volume - use one of the NoSQL Key-Value or Document Stores.
  • If you want to perform computationally-expensive tasks over simple, unconnected data structures - use a distributed processing framework (e.g. Apache Spark) with support for distributed data storage.
  • But if you want stretch the bounds of what's possible with your data - take a closer look at GraphBase.

Go to any other vendor, read any other discussion on graph stores and you'll be told that working with a large graph is all about traversals. You need to "think like a vertex", they'll say.

Sure, this works for large graphs, but only if their structure is simple. Working with complex graph structures this way will make your head explode. This is a serious shortcoming - because complex structures are where a Graph Database is most useful.

When you work with GraphBase, you work with graphs. GraphBase stores data as one large graph. Data is delivered to GraphBase as small graphs, a query to GraphBase returns data as a graph and the smallest transactional unit is a graph.

Even at the application level, it often makes sense to work with graphs, rather than objects. A graph can carry much richer information about the chunk of data you're working with.

GraphBase graph-manipulation tools also mean that data in graph form can be manipulated with dramatically-less code than is required for objects, "rows" and other traditional application data structures.

You can, for example, and() your graphs. Or you can turn them into a list of objects with a single method. Take a quick look at the Java API to see just now much simpler working with graphs can be.

Oh, and you can ditch that bloated ORM or other mapping layer - it's no longer required.

In traditional Database Management Systems you need to define a "schema". The schema is...

  • A map of where to put things and where to find them.
  • A mechanism to impose constraints on what those things are and where in the database they can go.

A database (physical) schema is also a straightjacket. Fill your database and you're locked into the structures defined by that schema. The only way to make significant change is to "migrate" your data. Imagine giant flocks of birds taking wing for a two-month-long journey from one end of the globe to the other. Data migration is no less an undertaking.


NoSQL databases are less-structured. The maps and constraints are basic or non-existent - and this includes the other graph databases. "No Schema" is touted as a positive feature of these database systems, but in truth you end up writing the schema in your application instead. That's not good practice - particularly for enterprise, where many applications and developers across many departments may be using the same DBMS.

GraphBase is different, and it's also unique amongst Graph Databases. We give you powerful maps and we also give you structures to impose the constraints you need. We do this with what we call "Frameworks". A framework is a graph that you "attach" to your data. Typically, the framework graph is a shallow tree of labels used to describe key vertices within your super-graph. Unlike a schema, you can add to or otherwise change a framework without impacting the existing data.

What's more, with GraphBase, there is no limit to the number of frameworks you can apply. And there's little to no performance cost when providing multiple rich frameworks. You can have one tree of labels for your stakeholders, another for your customers, another for the accounts department - and they can all provide a different "view" of the same data.

Simple label-trees are just the start. Your frameworks can also be...

  • Taxonomies.
  • Date or location rasters.
  • Symbol tables.
  • Natural structures - think anatomy, geography, genome maps, etc..

The GraphBase Semantic Framework is one example of a large and rich framework. It's a graph of 80,000 concepts representing more than one million English words. Rich frameworks like this can give your data unprecedented searchability. You can see this framework put to good use by the beth.ai conversational agent.

GraphBase also uses special frameworks to control access and to impose constraints when you need them. All the power of a schema, but without the pain.

There is no "standard" when it comes to building data graphs. Stores that support RDF (Semantic Web) and Property Graphs are most common, but these have failed to gain universal acceptance because they're not broadly-useful.

These first-generation graph stores have some impressive capabilities, but they don't do the basics well. First and foremost, a Graph DBMS has to be great at managing data. It has to be as easy-to-use as a traditional database and loaded with the features that Enterprise users expect. It also has to be highly-searchable, and fast.

These basic requirements heavily influenced our search for a base graph structure. But we also wanted a simplified preferred structure to meet these additional goals...

  • Promote data-as-graph Best Practice. The graph equivalent of RDBMS normalization.
  • Support Graceful Extension - where enriching your data doesn't break what's already there.
  • Make it easy to map language structures (including verbs) to simplify Natural Language Understanding (NLU) and search.
  • Allow a Data Landscape to emerge from your graph in support of "fuzzy" and serendipitous discovery of facts.

Graph Simple Form or GSF is that preferred structure. It helps us meet all our core and higher goals. GSF is a variation of what's referred to as a simple mixed-graph. This is what it looks like.

Each vertex or node has...

  • A 128-bit identifier.
  • A single payload that can be a simple property or a complex object. Or it can be empty.
  • A quantifier to flag that the vertex represents some (∃) or all (∀) of these.

Its arcs, edges or connections have these rules...

  • It may have a direction. Or not.
  • Direction is one of these types: "has", its opposite "is of", "mutual has" or "same as".
  • It can carry no other properties. In GSF, properties are for vertices.
  • There may only be one arc between any two vertices.
  • An arc may not connect a vertex to itself.

With GSF you can model any data structure. You can then build massive future-proof data graphs that are a pleasure to work with.