The primary disadvantage: you need an
sqlite3 executable with archive support when you need to recover your data. Depending on the circumstances, you may not have one handy, but you're far more likely to find a working
tar et al.
Here's why I'm being particularly pedantic about this:
- macOS system
sqlite3 versions are generally within spitting distance of up-to-date, but Apple only updates its software sporadically, and many Mac users may run backdated OSes for various reasons. Consequently, macOS system
sqlite3 before Mojave does not support archiving, so for portability, you'll definitely want to ensure that the Homebrew sqlite3 package is installed and updated.
- Homebrew on Linux defaults to installing a bottled (i.e. precompiled binary) sqlite v3.26 that somehow manages to not support archiving. I had to
brew install --build-from-source sqlite3 to fix that.
Those are just two examples that I have personal experience with. The platforms on which you plan to sqlar may have similar gotchas. Contrast all that with "it just works everywhere"
So, if you want to use the sqlar format in earnest, carefully consider all the circumstances and environments in which you'll be doing so. A rescue disk, for instance, may not have an archiving
sqlite3, and you really don't want to build sqlite from scratch during disaster recovery.
Aside from the availability of an archive-capable
sqlite3, you also need to consider the issue of file sizes.
Since an sqlar is basically an SQLite DB, it inherits all the limits of this file format. In particular, each file's data is stored as a BLOB, which has a default maximum size of 1 billion bytes. Also, SQLite query processing leads to each row being handled as a single BLOB, further lowering the file size limit.
Compare that with ZIP (232 for "classic ZIP", 264 for ZIP64) or GNU tar (unlimited), and you may have yet another reason to take the traditional route instead.