Of course, the flippant answer to this is that our codebases are already databases - the filesystem is our storage engine, commits are our transactions, etc. Bu

Of course, the flippant answer to this is that our codebases are already databases - the filesystem is our storage engine, commits are our transactions, etc. But is this the optimal way to store information? It would be very interesting to look at code as a graph database (of the https://github.com/tinkerpop/blueprints/wiki https://github.com/tinkerpop/blueprints/wiki family, for instance). In a way, one could see how a functional programming language defines entities and their relationships, and how a function is just a composition of other functions to which it could be linked. But do we want to write a graph operation every time we want to make an edit or add a feature to our code? Perhaps the textual codebases we have are the most easily editable visualization of the underlying "graph."