WAL-G: A Faster Way to Handle Postgres, MySQL, and MS SQL Backups

If you've ever waited on a database restore while your heart rate climbs, you know that backup tooling is one of those things you don't think about until you desperately need it. WAL-G is an archival restoration tool built for exactly that moment—and it's worth knowing about before you need it.

What It Does

WAL-G is an archival restoration tool for PostgreSQL, MySQL/MariaDB, and MS SQL Server, with beta support for MongoDB and Redis. It's written in Go, which means you get a single binary you can drop onto a server without dragging a runtime along with it.

The project is the successor to WAL-E, and it makes a few deliberate changes to how that older tool worked. For Postgres specifically, WAL-G uses non-exclusive base backups, which is a meaningful shift from the WAL-E approach. It also leans on multiple processors and supports a range of compression methods—LZ4, LZMA, ZSTD, and Brotli—so you can pick your tradeoff between speed and storage size rather than accepting whatever the tool decided for you.

If you want the deeper backstory on the original design, the README points to a Citus Data blog post titled "Introducing WAL-G by Citus: Faster Disaster Recovery for Postgres," which is a good place to go if you care about the reasoning behind the architecture.

Why It's Cool

Compression is a first-class choice, not an afterthought. The default is LZ4—fast, but with a mediocre compression ratio. If you'd rather trade CPU time for disk space, you can switch to LZMA, which the README says compresses backups roughly six times better than LZ4. Brotli and ZSTD land in the middle, around three times better than LZ4. That's a real spectrum, and being able to move along it per-environment is genuinely useful. You can also tune ZSTD further with WALG_ZSTD_LEVEL (fastest, default, better, best), so the knob-turning doesn't stop at picking a codec.

It covers more than one database. A lot of backup tooling is single-engine. WAL-G supports PostgreSQL, MySQL/MariaDB, and MS SQL Server, with MongoDB and Redis in beta. If your infrastructure isn't monogamous—and most aren't—that's one less tool to learn.

Configuration is flexible without being fussy. You can configure WAL-G through environment variables or a config file. The config file path can be set with the --config flag or the WALG_CONFIG_PATH environment variable, so you don't have to repeat the flag on every invocation. And because it uses the viper package under the hood, you can write your config in JSON, YAML, envfile, or whatever other format viper supports. Every documented variable works either way, which means you can keep secrets in the environment and everything else in a file if that's how you like it.

Installation is a tarball and a mv. Precompiled Linux AMD64 binaries live under the Releases tab, named with a wal-g-DBNAME-OSNAME convention so it's obvious which one you want. No package manager gymnastics required for the common case.

Shell completion exists. It's a small thing, but wal-g help completion gets you bash and zsh autocompletion, which suggests the authors actually use this thing daily.

How to Try It

1. Head to the Releases tab and grab the binary matching your database and OS. For Postgres on Ubuntu 24.04, that's wal-g-pg-24.04-amd64.tar.gz.

2. Decompress and install it:

tar -zxvf wal-g-pg-24.04-amd64.tar.gz
mv wal-g-pg-24.04-amd64 /usr/local/bin/wal-g

1. Configure your storage backend. This is the part you can't skip—the README directs you to the STORAGES.md file in the repo for the details, since where you store backups depends entirely on your setup.

2. Set your compression method if you don't want the LZ4 default:

WALG_COMPRESSION_METHOD=zstd

1. Optionally point WAL-G at a config file so you're not passing flags constantly:

WALG_CONFIG_PATH=/etc/wal-g/config.yaml

The full documentation lives at wal-g.readthedocs.io, and the source is at github.com/wal-g/wal-g. There's also a chat channel linked in the README if you get stuck.

Final Thoughts

WAL-G isn't trying to be a managed backup service or a shiny control plane—it's a command-line tool that does one job and does it with an unusual amount of attention to the details that matter during an actual recovery. The compression options alone make it worth a look if you're currently storing uncompressed or poorly compressed backups, and the multi-database support means it might replace more than one thing in your stack. If you're running Postgres, MySQL, or MS SQL Server in production and you haven't revisited your backup tooling in a while, this is a reasonable place to start. Just budget time for reading the storage docs before you flip anything on.

Follow @githubprojects for more developer tools and open source projects.