Hacker News Reader

Comment by candiddevmike | Hacker News Reader

Anyone reading the above: please don't do this. Git is not made for database backups, use a real backup solution like WAL archiving or dump it into restic/borg. Your git repo will balloon at an astronomical rate, and I can't imagine why anyone would diff database backups like this.

View on HN

It really depends on your database size. This works just fine for ~300MB databases. Git gc takes pretty good care of the fluff and once every couple of years I reset the repository to prune the old snapshots. The big plus is that you can reuse your existing git infrastructure, so the marginal setup costs are minimal.

You can always switch to a more specialized solution if the repository size starts bugging you, but don't fall into the trap of premature optimization.

Git GC won't do anything here unless you're deleting commits or resetting the repo constantly. Every commit will keep piling up, and you will never prune anything like you would a traditional backup tool. The day you do decide to start pruning things, expect your computer to burst into flames as it struggles to rewrite the commit history!

Using a real database backup solution isn't a premature optimization, it's basic system administration.

Agree. Nothing wrong with doing what works for most things, but with backups it's easier to use an appropriate process from the start. It's easy enough and saves you grief later.

I haven't dug into too much detail, but doing git gc did have a noticeable effect on size and subsequent update performance. I assume, some temporary artifacts got consolidated.

Also resetting the repository once every 1-2 years, and keeping the old one for a while is fine for smaller setups.

Depending on your business size and the amount of resources you want to allocate towards "basic system administration", accomplishing the same task with fewer tools could have its advantages.

There wouldn't be anything to prune, but git gc also does compression.

>It really depends on your database size.

This isn't just about size though. You're storing all customer data on all developer machines. You're just one stolen laptop away from your very own "we take the security of our customers' data very seriously" moment.

Nobody said the devs have access to those repos

True. It depends on how exactly those repositories are structured and managed. Hopefully it's not quite as bad as I imagined.

I still think that database size is not the only consideration.

Not every database is huge. It could be a good solution in certain circumstances.

Reply on news.ycombinator.com