That was my solution: pipe the output from the SQLite CLI's <code>.dump</code> command into a compactor. Problem is, because of how efficient compactors work, even that will temporarily use about the same amount of space as the original file. With regard to a file system with compression built-in, we should take the concept to its limit and imagine doing it on Apple's Filesystem APFS. In that system two sectors with identical contents can be collapsed into the same sector, and two files with the same contents can be collapsed into the same file. If you call the OS API to duplicate a file, all that happens is another directory entry is created, pointing to the original data. (It's more complicated than this, but you get the idea.). If one of the two files is changed the change is stored as deltas until the OS decides that it's not saving any space by doing so. Using that, you can create as many copies of the original file as you want, and use hardly any extra space. But does it do what the OP wanted ? Does this qualify as a backup in their case ? If there's a disk failure, you lose both files.