This is a bad idea. Every use case they mention has a simpler, more performant option that’s easier to maintain. It reads like someone asked an LLM if they can use git as a database, then decided to post that to the web because being controversial gets clicks.
That's exactly what they're doing, it's just driving engagement for their sales:
> While Git makes an interesting database alternative for specific use cases, your production applications deserve better. Upsun provides managed PostgreSQL, MySQL, and other database services
This should do the opposite: I would not trust anyone who thinks that this is a solution worth considering for the use cases they identified as my database service provider.
ex-insider here, actually Git is used internally as a database of sorts. And it makes sense for many other reasons not cited. You are guaranteed to be able to access the "database" in a decade or two if you need to restore stuff without having to worry about binary compatibility. For more complex data types you can actually use an Sqlite database you save in a git-note. But this is very much about a very specific use-case. And the last paragraph could have been written less salesy and more "don't try this at home, don't run with scissors kinda message".
So this is kinda the contrary to "use Postgres for everything" vibe.
Consider using Git as an actual database if you were considering using Sqlite or simple text files, or consider actually wrapping those with Git because it will give you quite a bit of extra oomph with very little effort.
I personally used git as a database on a project where we had just 200 records. With infrequent changes. Some bulk updates. That needed, for weird reasons, to be synchronized every ~12 months, yeah, and some of the nodes were air-gapped. As far as I know, more than 15 years later this is still running with basically 0 maintenance (other than git being upgraded with OS updates).
Why is it a bad idea? They only mention one use case, but I have been in a similar situation where git was already being used and, like them, I simply needed to connect into the same functionality with my service. Sure, I could have come up with all kinds of complex solutions to synchronize git with other databases... Or I could just use git. It works fine. Why wouldn't it? That's the type of workload git is designed for.
The article lists the following "strengths", which imply the use cases. Let's discuss!
1. Built-in audit trails. Git's a hash tree, right? So you can't tamper with it? Wrong. You can force push and delete commits. By default, git garbage collects dangling commits and old branches. In order to make a cryptographic audit trail, you'd need to publish the hash tree publicly and non-deniably so your auditor can know if you tampered with the logs.
2. Atomic transactions. Many databases support these, with a lot of granular control over the details. Postgres is one of them. (The ones that don't may have good reasons.) Git does not have much granular control; merges are not guaranteed to keep any data intact.
3. Distributed architecture. Good point. But wait, that's not really true. How do we decide what the real "main" is? It's whatever main is on your upstream, which in almost all cases is a centralized server. And if it's not, git doesn't provide any automated tooling for dealing with conflicts between multiple sources of truth (no algorithm for byzantine generals, for example). So this is a red herring.
4. Content addressing. Does this mean a commit hash? Like, say, an _index_ but without the ability to index over any other data?
In my career, I have seen git used twice as a "database" in a sensible way: for tracking source code changes (that is, changes to structured text files). This is precisely the use case it was designed for. And in both cases, it was actually underutilized---no real merge capability, just file versioning, so they could have gone simpler.
But git is not even good for most "collaborative text editing" since merge handling is not automatic. You wouldn't use it for a google-docs style platform, for example.
> for tracking source code changes (that is, changes to structured text files).
Which is exactly what they claim to use it for.
> so they could have gone simpler.
Maybe, but they also claim that it is a desirable, maybe even necessary, property to ingrate with existing git use. So you can only go simpler until you have to actually interface with git and then any possible downsides of git come rearing their ugly head at this point anyway. So what have you gained by just not using git from top to bottom?
I will grant that there is one use case where git is better than postgres, which is tracking source code changes. But to use git as a database instead of postgres is ... misleading? Clickbait? Trolling?
> But to use git as a database instead of postgres is ... misleading? Clickbait? Trolling?
Contextual.
You are right that the article is a bit hard to follow where it goes down roads that it also says you shouldn't actually do, but that is there just to explain that git is a database, which isn't as obvious as it should be to some people. There are no doubt better ways to get that idea across, but someone in the business of providing managed Postgres hosting isn't apt to have writing long-form text as a core competency. Nor should one need to have it as their core competency. Writing is for everyone — even those who aren't particularly good at it.
