Git in Postgres

52 points by abhin4v

Irene

Huh. Well, kudos for actually taking this to the logical extreme. It's good to see creative things like this, though I admit I'm still somewhat hostile to the idea.

endsofthreads

Out of curiosity, why are you hostile to this idea/approach?

Student

Where’s the benchmarks? The readme is also instructive https://github.com/andrew/gitgres and links to other database-based libgit2 backends also without benchmarks.

stchris

Getting from a handful of large forges to a lot of small ones probably depends on a forge you can stand up with docker compose up and back up with pg_dump, and that’s a lot easier when there’s no filesystem of bare repos to manage alongside the database.

I sort of agree, but I would go one step further and say that a single binary is even better than a docker compose setup. This one only needs ssh access.

op

https://github.com/charmbracelet/soft-serve

this is not a fully featured forge however, this is just an interface over a collection bare git repos.
- stchris
  
  Sure, agreed. But neither is the PoC project mentioned in this article. But both could be extended to become more fully-fledged forges and I was commenting on this aspect.
chad

We often store application config in source control because my attitude is things I assume will rarely change are not worth building a datastore/UI for.

Then, when we find which things are changing enough that it's worth building the db/ui for, we run usually build the simplest MVP thing but sadly lose out on change control and history. Yes, we should build this into the database with version numbers etc. but it feels like such a common problem that there should be a generic data-type for this.

Storing git objects in postgres is probably overkill for this specific use case but I have considered it.
- Daniel-V1
  
  Would dolt of doltgres work for your use cases? https://www.doltgres.com/
yorickpeterse

I vaguely recall that at GitLab we experimented with using Git and some database as a backend. I don't remember if it was MySQL or Redis, but I recall that the performance was so horrible it never went beyond the "This looks cute but we'll never use it" stage.

We ran into similar issues when we tried to store Git data on CephFS due to how "chatty" Git is (or at least was at the time) when it comes to file system access. That's fine if the data is stored on a local disk, but the moment you throw a network based storage into the mix all hell breaks loose.

I think for a VCS to work with a network backend you need to design it with that in mind from the start, as retrofitting it is unlikely to work once you start hosting a bunch of active repositories.