$ pg_dump dbname | restic backup --stdin --stdin-filename dbname.dump --tag dbname -q
With restoring as simple as:
$ restic dump latest --tag dbname dbname.dump | psql dbname
I should probably stick a gzip/gunzip between those two commands.
If it does compression, then it's not an opaque process to it. But if you do it, you are essentially obfuscating the structure of the data.
The result is a valid gzip file with a few percent less compression, but friendly to deduplication (which is what rsync does).
You cannot stick a compression step before restic, because it will mess up the deduplication - the chunker will not find the same chunks, and will not be able to find out which files have same contents (not as easily at least).
And you cannot stick it after restic, compressing the backup archives (or storing them on a compressing filesystem), because those are encrypted, and any encrypted file has high entropy and does not compress. (It doesn't help that restic makes the encrypotion mandatory).
So no, compression really needs to be an integral step in a backup system. Restic is definitely lacking in this regard.
Unfortunately it does not seem like it's a prioritised feature given that it has been planned since late 2014.