The days of storing data in what is basically a glorified set of spreadsheets is coming to an end. The new hip tech is Graph Databases. To be clear I am NOT the expert on these, as a matter of fact I am barely conceiving what this tech is. But that is how I always start out with new tech.

Here is what I know: Graph Databases use Graph Theory to organize data.

Relational DBs are basically a set of spreadsheets with completely unrelated information stored next to each other because they happened to be created close to the same time and got an integer ID that is one away from each other.

Graph DBs instead store data as “a network of entities and relationships”.

Benefits:

Basically, if I understand it right, they learn how to cluster data with similar relationships near relevant data.

As opposed to the relational DB example this means that data from customer A who has nothing to do with customer B will all be centralized “near” customer A.

What does that mean from an infrastructure standpoint? You know me, I want to know how to host this thing and scale it to billions of users without breaking the bank. So I did some googling on how to shard Graph DBs and the found the following:

…graph sharding is an NP problem anyway, which is way much harder than sharding in SQL.

Which I then had to google NP problem to remember what that was.

After digging in there is not 1 standard way that these things scale; they are each designed differently. Great….

I think I will start with digging into one specific Graph DB to get my bearings then work my way out. If you are interested in hearing more let me know.

GraphDB Expertice:

If you happen to be a Graph DB expert or know one and want to introduce me I would love to record an interview with a GraphDB Expert and publish it for everyone's benefit. Please comment, email, DM or send smoke signals if you or anyone you know is a GraphDB expert.