The current KDBX XML format creates unnecessary friction for developers and users alike, from brittle schemas to storage inefficiencies. SQLite with SQLCipher offers a compelling solution that addresses these pain points while maintaining security and backward compatibility.
The KeePass ecosystem has long stood as a bastion of security and data sovereignty in the password management world. Yet beneath its sterling reputation lies a technical foundation that increasingly struggles to meet modern demands. The KDBX XML format, while revolutionary in 2007, now creates friction points that hamper both development and user experience.
The Problems with KDBX
At its core, a KDBX 4.1 file is an encrypted, authenticated, gzipped XML document containing password entries, attachments, and custom data. This architecture creates several fundamental issues that compound with each new feature request.
The most immediate problem is that every edit—no matter how minor—requires rewriting the entire file. This approach, combined with loading the complete database into memory, creates significant performance bottlenecks, especially for mobile clients and larger databases. Users with databases exceeding 10-100MiB frequently encounter out-of-memory errors during autofill operations.
But the deeper issue lies in the schema's brittleness. New features cannot be integrated natively into the XML tree without breaking compatibility for older clients. This has led to a shadow ecosystem where features are shoehorned into custom attributes using inconsistent naming conventions and data formats.
Consider the TOTP implementation saga: before native support, plugins implemented time-based one-time passwords using various field names and parameter formats. When KeePassXC standardized on the otpauth URI format, and later when KeePass Proper implemented its own TimeOtp-Secret format, users were left with incompatible implementations across clients. Passkey support suffered a similar fate, with five different attributes cluttering the user interface and creating interoperability headaches.
Storage Inefficiencies
The XML format's handling of attachments and icons exacerbates these problems. Custom icons are stored as base64 strings within the XML, causing approximately 33% file size inflation per icon. This approach also dramatically increases memory usage and slows access times, particularly on mobile devices where everything must be loaded into memory.
These inefficiencies become particularly problematic when users treat their password database as a general-purpose secrets manager, attaching passport scans, ID documents, and other large files. While extreme cases involving 500+MiB databases are outliers, many users operate in the 10-100MiB range—well within the territory of slow mobile unlocking and memory errors.
Governance Challenges
The current governance structure compounds these technical issues. Dominik Reichl has maintained the KDBX format for decades, bringing valuable conservatism and compatibility considerations. However, this centralized control creates tension with the ecosystem's evolution.
The KeePassXC fork, with its significantly larger user base and more active development, often finds itself implementing features that later require backward-compatible workarounds. This "first mover advantage" creates a matrix of incompatibilities that could have been avoided through collaborative specification development.
As one KeePassXC maintainer noted, the current approach of Dominik unilaterally accepting or rejecting proposals feels one-way, despite appreciation for the communication. The interconnected shadow schema that has developed across forks is unsustainable.
Why SQLite with SQLCipher is the Right Answer
A transition to SQLite with SQLCipher offers elegant solutions to all three major problem categories.
Schema Flexibility
SQLite's relational structure would allow current jerry-rigged features to have proper database representation rather than cluttering user-facing attributes. New authentication methods could be accommodated by simply adding tables, with old clients gracefully ignoring unsupported features. This eliminates the breaking change problem entirely.
Storage Efficiency
SQLite's architecture addresses the storage inefficiencies head-on. Icons and attachments can be stored as binary blobs rather than base64 strings, dramatically reducing file sizes. More importantly, SQLite doesn't require loading the entire database into memory, enabling better performance for larger databases.
The encryption model also enables delta synchronization. With SQLCipher's encrypted pages, changing one password only modifies its page rather than the entire file. This means a 4KiB change instead of re-uploading a 20MiB file—a significant improvement for users on metered connections or cloud sync services.
Governance Modernization
A SQLite-based format provides an opportunity to modernize the governance structure. Rather than a benevolent-dictator-for-life model, the ecosystem could move toward a more democratic consortium approach, with major clients collaborating on specification development from the start.
Addressing Anticipated Concerns
Critics raise several valid concerns about such a fundamental change, but each has reasonable solutions.
Transaction Safety and Single-File Philosophy: SQLite's auxiliary files (WAL, SHM) aren't necessary for robust transactions. Options include VACUUM INTO on every save, setting PRAGMA journal_mode = DELETE, or using rollback journals that create temporary files deleted after transactions—similar to existing backup mechanisms in KeePass clients.
Backward Compatibility: While some users still operate on KDB files from the 1990s, the majority want modern features. The migration process would be straightforward—a simple data map between two well-documented formats. This mirrors the KDB to KDBX transition, which yielded far less benefit for a breaking change.
Preservation and Human Readability: Both formats ultimately exist as encrypted blobs when in use. The XML export format can be preserved for human readability and interoperability with other password managers. SQLite is also recognized by the Library of Congress for long-term preservation value.
Dependency Concerns: SQLite is remarkably lightweight and ubiquitous. The contacts app on most phones uses SQLite despite doing far less than a password manager. With 100% branch test coverage and deployment in mission-critical systems from NASA to Airbus, SQLite's reliability is well-established.
Metadata Leakage: SQLCipher's fixed page sizes mean file size growth is less linear than KDBX files. If it's secure enough for Signal and other password managers like CodeBook and Enpass, it's certainly secure enough for KeePass.
The Path Forward
The technical case for SQLite is compelling, but implementation requires ecosystem coordination. KeePassXC, as the de facto leader, should spearhead specification development while including major mobile developers from the outset. The abandoned KeePassXC-Specs repository from eight years ago demonstrates both the need and the challenge of such coordination.
For users, supporting this transition means engaging in public development forums and channels. The current KDBX format served admirably for over a decade, but the ecosystem has outgrown its constraints. SQLite with SQLCipher represents not just a technical upgrade but an opportunity to align the governance structure with the community's needs.
As password management becomes increasingly central to digital life, the tools we use must evolve. The crab may be the ultimate crustacean, but in password management, a relational backend represents the natural optimum for complex data management. SQLite isn't just an improvement—it's the logical next step for an ecosystem that has outgrown its XML roots.
References:
Comments
Please log in or register to join the discussion