[jansommer]

Something to consider when using SQLite as a file format is compression (correct me if I'm wrong!). You might end up with a large file unless you consider this, and can't/won't just gz the entire db. Nothing is compressed by default.

[crazygringo]

Sure. But if you have reasonably small files just compress the whole file, like MS Office or EPUB files do.

Or if your files are large and composed of lots of blobs, then compress those blobs individually.

Whereas if your files are large and truly database-y made of tabular data like integers and floats and small strings, then compression isn't really very viable. You usually want speed of lookup, which isn't generally compatible with compression.

[lateforwork]

It can be compressed, see https://sqlite.org/sqlar.html

[nh2]

Please do not use second resolution mtime (cannot represent the high accuracy mtime that modern OSs use, so packing and unpacking , or causes differences eg in rsync), or build anything new using DEFLATE (it is slow and cannot really be made fast).

[mort96]

This seems completely orthogonal? This is an alternative to zip and tar built on SQLite:

> An "SQLite Archive" is a file container similar to a ZIP archive or Tarball but based on an SQLite database.

Your parent comment said that when you're using SQLite as an application format, the content in the database don't get compressed. These two things have nothing to do with each other.

[jansommer]

Archive Files is for blobs as far as I understand. All your other data remains uncompressed?