3 ms·

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

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. Edit: formatting

9rx 1y ago
> 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?
- _alternator_ 1y ago
  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?
  - 9rx 1y ago
    > 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.

9rx 1y ago

> 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?

_alternator_ 1y ago
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?
- 9rx 1y ago
  > 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.