SQLite throws SQLITE_FULL when it cannot complete a write operation because disk space is exhausted or temporary directories lack sufficient space. Free disk space, redirect temp files, or enable auto-vacuum to resolve this issue.
SQLITE_FULL (error code 13) indicates that SQLite could not complete a write operation because available disk space is exhausted. This error can occur when writing to the main database file or to temporary files SQLite creates during operations. Importantly, you may encounter this error even when substantial disk space appears available on your primary partition—the issue often stems from temporary file directories on separate, smaller partitions running out of space.
Run df -h (Unix/Linux) or dir (Windows) to see free space on all partitions. Pay special attention to the partition containing your database file and temporary directories.
# Unix/Linux
df -h
# Check SQLite temp directory specifically
echo $SQLITE_TMPDIRIf the partition is full or nearly full, proceed to step 2.
Delete unnecessary files or archives to reclaim space. If using the database for testing or caching, clear old data:
-- Delete old records (example for timestamps)
DELETE FROM your_table WHERE created_at < datetime('now', '-30 days');Alternatively, move files to external storage or increase storage capacity.
If the issue is temp directory space (common when /tmp is on a small partition), redirect SQLite to a partition with more space:
# Set SQLITE_TMPDIR to a directory with ample space
export SQLITE_TMPDIR=/path/to/large/partition
# Your application now uses this directory for temp filesFor persistent configuration, add this to your shell profile (.bashrc, .zshrc, etc.):
echo 'export SQLITE_TMPDIR=/path/to/large/partition' >> ~/.bashrcEnable auto-vacuum pragma to automatically reclaim space from deleted records:
PRAGMA auto_vacuum = FULL;For existing databases, run VACUUM once to reclaim space (ensure sufficient temp directory space first):
VACUUM;Note: VACUUM is a maintenance operation that can take time on large databases.
If using WAL mode (Write-Ahead Logging), monitor WAL file growth and ensure connections are properly released:
-- Check WAL mode status
PRAGMA journal_mode;
-- Force checkpoint to reduce WAL file size
PRAGMA wal_checkpoint(TRUNCATE);In your application code, ensure database connections are closed/released regularly:
// Node.js example
const db = new Database('file.db');
try {
// use db
} finally {
db.close(); // Always close the connection
}AUTOINCREMENT Edge Case: If your table uses AUTOINCREMENT, the insert can fail when the internal counter reaches its maximum (9,223,372,036,854,775,807 for 64-bit). This is rare but possible in long-running applications with high insert rates. Solution: either use a different key strategy or periodically archive/delete old records.
Database Size Limits: 32-bit systems have a practical 2GB database file limit due to signed integer file offsets. On 64-bit systems, the limit is much higher. Consider upgrading to 64-bit systems if hitting this limit.
Disk Quota Systems: Enterprise environments often enforce per-user or per-application disk quotas. If your application is quota-limited, coordinate with system administrators to increase the allocation or implement data retention policies.
SQLITE_CORRUPT_VTAB: Content in virtual table is corrupt
Content in virtual table is corrupt
SQLITE_IOERR_WRITE: Disk I/O error during write
Disk I/O error during write operation
SQLITE_READONLY: Attempt to write a readonly database
How to fix "SQLITE_READONLY: Attempt to write a readonly database" in SQLite
SQLITE_CONSTRAINT_PRIMARYKEY: PRIMARY KEY constraint failed
How to fix "SQLITE_CONSTRAINT_PRIMARYKEY" in SQLite
SQLITE_READONLY_DBMOVED: Database file has been moved since opened
How to fix 'SQLITE_READONLY_DBMOVED: Database file has been moved since opened'