Taming the Software Beast: Using git as a database

Software is a fickle beast. Creating easy-to-use software that attempts to solve the problem at hand is difficult to do. Also, the coupling of problem and solution adds to the complexity - feed one and the other grows hungry.

Developers are continuously trying to tame this beast. Standard engineering practices help ease demands on developers. One common caution that we all are familiar with is not to ‘reinvent the wheel’ and, expanding on this maxim: how can we adopt a solution to a different set of problems? 

This approach is simple enough for the smaller elements of the project, but for the more substantial portions, one needs to be cautious. Most of the time, one size does not fit all.  

At CompliSpace we have adopted a technology initially built for other reasons and re-purposed it for the management, syndication and distribution of content, which will drive the majority of our products.  

First, I’ll briefly describe the problem that differentiates our content distribution system to others. 

We have to distribute tailored, policy content to our hundreds of clients. The spanner in the works is that a large majority of our clients are made up of a tree (sometimes web) of smaller organisations. Content syndication occurs from parent to child, and possibly from sibling to sibling, where CompliSpace is the grandparent of all clients. Each organisation can maintain their version of the content and test alternative material, and at the same time keep up with the necessary changes made by CompliSpace, their parent or sibling. 

Okay, so we have the problem, what’s a possible solution for storing and managing this web of data? What about a relational database? They can do anything these days. They are usually a go-to solution, but unfortunately, if we used one we would end up using various cool database patterns, and ultimately complicating the matter. 

It’s much better to keep things simple when working with complex data structures (I already have enough relationship problems in my life!).  

So, if not that, what about graph databases? They handle data stored in a web structure. Alas, not a viable option either - the team doesn’t have experience with these.  

What we really needed was a data store that comes with versioning, distribution and branching of data. Sound familiar software creators? If you thought git could solve this, well…bingo! We opted to use git as a data store and get all the git goodies - versioning, branching, cloning – for free. Git, built as a version control system for code, is at its core a key-value data store. It does everything we wanted it to do with the content data. And discovering git-based solutions like Gitbook and Netlify CMS further validated our choice. Also, Github does to code what we want to do to content. 

Because of the power of git, our clients can create new content, archive and work with alternative versions, while still being aligned with the primary source of the CompliSpace content. Git as a database!

Burak Cankurtaran

Burak Cankurtaran

Burak is an experienced lead with demonstrated capability in building and leading large software projects across a multitude of fields and software stacks. With a good track record of leading teams and working within all aspects of software development. He has also worked as a scientist in computational quantum physics.

CompliSpace Engineering

Enginerring blog