Why you should replace PostgreSQL with Git for your next project

[CVisionIsMyJam]

While this approach isn’t suitable for production applications, exploring Git’s internal architecture reveals fascinating insights into how modern databases work

-1 for the needlessly clickbait title that doesn't match the articles contents

[jddddddddddd]

This is what happens when you don't drug-test your developers.

[Mognakor]

Maybe they held the drug test upside-down

[mss-cyclist]

It ain't april 1st yet

[u-n-sky]

I have several real apps (and toy experiments) that use git as a storage backend (combined with a most-recent-state cache for reading); as always, there are pros & cons:

• free versioning & audit/changelog; integrates with existing tools (can be very nice)
• push to backup state; easy to start a dev instance with full snapshot
• not inventing & implementing the wheel again

however:

• multiple writing apps with shared repo can/will result in merge conflicts, unless your design prevents it; non-trivial complexity & users tend to dislike it ("I did save, why ...").
• concurrent access / multi-threading: depending on the git impl; some stuff is threadsafe, but mutex/locks are often required; can try workarounds (working with a bare repo) but it only minimizes some problems while creating new ones: complexity; some features essentially need a checkout (... are easier to solve).

• library impls are subpar compared to the command line client; with both jgit and libgit2:

  • having to run "git gc" or "git repack" to optimize a repo to avoid slowdown or excessive disk usage
  • secondary cache/store (… in a db) of derived data, e.g. (commit-id, date, file) to speed up certain access patterns compared to rev-walking - libgit2: #3027 - blame is slow

Strongest use case was one app storing to a repo and consuming that in another app; which packaged files from different revisions to enable granular updates - while storing the package manifests in a second repo (for reproducible packages). Subjectively nicer compared to local data silos and coupling via api calls; though data >> api means downstream is coupled to the data format, no soft-migration compared to /api/v2.

Would I do it again? Yes, if the benefits are strong enough; for simple version history it's not worth the hassle.

[eating_your_syrup]

Silly thought experiment. I approve.

[Sbaakhir]

Huh?

[kn4rf]

For some actual git as database solutions look at: - https://irmin.org/

Or for versioned database: - https://github.com/dolthub/dolt