Is Git a NoSQL Database?

Caring about branding things NoSQL isn't just not useful, it's harmful because it replaces really understanding things (like how a particular method works, and what it's good for) with a useless shorthand. Reminds me of a quote:<p>“You can know the name of a bird in all the languages of the world, but when you’re finished, you’ll know absolutely nothing whatever about the bird… So let’s look at the bird and see what it’s doing — that’s what counts. I learned very early the difference between knowing the name of something and knowing something.”<p>R. Feynman - "The pleasure of finding things out" 1981

A long time ago, I wondered: "Aren't all Filesystems NoSQL Databases?" Just use the filename as the key, and the contents as the value.<p>It turns out that the answer is "Yes", but filesystem performance is optimized for use cases other than being a NoSQL database. If you actually want to use a NoSQL database with better performance and probably more features then you're better off using something designed as a NoSQL database.

"NoSQL is a bullshit marketing term coined to insight ire in the heart of DBA's."<p>Git can be an awesome place to store data for your web app, or it could suck, CouchDB may be awesome, it also may suck, I realise that sometimes its useful to come up with broad marketing terms to lump together related technologies, I think the current thing of all new web stuff under "html5" is perfectly fine, but in the case of new data stores I think its just pointlessly damaging, a lot of these are very different applications with their own advantages and disadvantages.

Guideline: If it allows you to store things but doesn't understand SQL, it's a NoSQL database.<p>Cookies? NoSQL database. DVDs? NoSQL database. SQL database engine? NoSQL database.<p>Seriously, use whatever suits your use case and a plague on the term.

I believe one of the main points of the article, and the blog post it references, is that SQL solutions solve the CAP Theorem problem for C + one other and most NoSQL solutions solve for A and P (i.e. allowing temporary inconsistency).<p>Git provides Availability and Partition Tolerance and therefore, and provides solid mechanisms for conflict resolution - merges. So it that way it is a NoSQL solution.

This sounds to me a little like making an argument for its own sake. That said, the Git data model is really elegant and interesting, and it's a good fit for many applications that need a fully versioned data store. The main issue is a single point of contention (the HEAD pointer) on every update, but if you parallelised all the update process except for that the performance would probably be ok for updates that don't otherwise conflict - certainly a good fit for a non-distributed document store. I've considered implementing the data model in something like Redis to see how it works, I think it would be pretty nice.

This is good, I think people are close to realizing that the term NoSQL is silly and practically meaningless. In a few years we'll all have a good laugh about it.

On a project I worked on that require massive scale distributed, time-delayed merging, we once pondered the use of putting XML-ized objects in Git and merging it that way. Don't think it was fast enough with hundreds of thousands of objects and we still would have to had built a XML merger.

I've always thought Twitter was a NoSQL datastore even before the term NoSQL was invented. So many services use Twitter as a quasi-data store and do analysis on that data. For example, StockTwits.