[jiggawatts]

In a word: Facebook.

A more technical use case that I liked was a system that can analyse the configuration of resources across and entire network and find a "path" from a normal user account to a full admin privilege.

Something like: "Helpdesk user A can reset the password of a service account that can write to a file share that contains a script that is run on logon by every user including the full admin, allowing user A to trigger an action in the context of an admin B, making them equivalent to an admin."

You map out "things" on the network like file shares, security groups, accounts, etc... with links between them, and then ask for the shortest path from A to B.

[randomdata]

> In a word: Facebook.

Which, funnily enough, uses a relational database.

[bryanrasmussen]

I'm betting Facebook uses a lot of different types of databases.

[randomdata]

No doubt, but the core product known for being graph-y is based on MySQL.

Indeed, there is a graph data store (TAO) built on top of that base, but as we're talking about databases...

[jiggawatts]

Many graph databases are relational "under the hood". The graph part is often just a specialised index.

[randomdata]

Just as Facebook uses MyRocksDB (a KV store) underneath MySQL. There is a definite turtles all the way down.

But where do you draw the line? Is your Ruby on Rails CRUD app that exchanges JSON documents a document database? Fundamentally, what's the difference between said Rails app and TAO, aside from one being centred around documents and the other graphs?

Surely "base" is meant to be more specific?