Problem
The ~/.apx/logs/db SQLite database grows without bound because deleted rows are never reclaimed. On my machine it reached 111 GB, of which only ~10 GB is actual data β the remaining ~101 GB is free/unused pages.
Root Cause
The cleanup logic in crates/db/src/logs.rs correctly deletes rows older than 7 days (RETENTION_SECONDS = 604800) every hour via cleanup_old_logs(). However, SQLite's DELETE only marks pages as free β it does not return disk space to the OS. No VACUUM or auto_vacuum pragma is used anywhere, so the file only ever grows.
With ~3M rows/day being written by the flux OTLP collector, the churn is significant and the wasted space accumulates quickly.
Suggested Fix
One or more of:
PRAGMA auto_vacuum = INCREMENTAL set at database creation time, with periodic PRAGMA incremental_vacuum calls after cleanup
- Periodic
VACUUM after the hourly cleanup_old_logs() (though this rewrites the entire DB and may be expensive)
- Row count or file size cap as an additional safeguard
Workaround
Users can manually reclaim space:
sqlite3 ~/.apx/logs/db "VACUUM;"
Or delete the file entirely and let apx recreate it:
rm ~/.apx/logs/db ~/.apx/logs/db-wal ~/.apx/logs/db-shm 2>/dev/null
Environment
- macOS (Darwin 25.3.0)
- apx installed via
~/.local/bin/apx
- SQLite version 3.46.0
Problem
The
~/.apx/logs/dbSQLite database grows without bound because deleted rows are never reclaimed. On my machine it reached 111 GB, of which only ~10 GB is actual data β the remaining ~101 GB is free/unused pages.Root Cause
The cleanup logic in
crates/db/src/logs.rscorrectly deletes rows older than 7 days (RETENTION_SECONDS = 604800) every hour viacleanup_old_logs(). However, SQLite'sDELETEonly marks pages as free β it does not return disk space to the OS. NoVACUUMorauto_vacuumpragma is used anywhere, so the file only ever grows.With ~3M rows/day being written by the flux OTLP collector, the churn is significant and the wasted space accumulates quickly.
Suggested Fix
One or more of:
PRAGMA auto_vacuum = INCREMENTALset at database creation time, with periodicPRAGMA incremental_vacuumcalls after cleanupVACUUMafter the hourlycleanup_old_logs()(though this rewrites the entire DB and may be expensive)Workaround
Users can manually reclaim space:
Or delete the file entirely and let apx recreate it:
Environment
~/.local/bin/apx