3 ms·

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

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.

candiddevmike 6y ago
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.
- danmur 6y ago
  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.
- deleted 6y ago
  [deleted]
- john_moscow 6y ago
  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.
- Izkata 6y ago
  There wouldn't be anything to prune, but git gc also does compression.
fauigerzigerk 6y ago
>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.
- robjan 6y ago
  Nobody said the devs have access to those repos
  - fauigerzigerk 6y ago
    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.

candiddevmike 6y ago

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.

danmur 6y ago
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.
deleted 6y ago
[deleted]
john_moscow 6y ago
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.
Izkata 6y ago
There wouldn't be anything to prune, but git gc also does compression.

fauigerzigerk 6y ago

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

robjan 6y ago
Nobody said the devs have access to those repos
- fauigerzigerk 6y ago
  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.