SQLite

Own SQLite's storage, connection, transaction and migration behavior. Use sql for shared relational/query design and sql-performance for measured tuning. Language database skills cover driver APIs; the actual SQLite runtime and application contract determine engine behavior.

The normal target is roughly 100 MB–1 GB, with room to grow. File size alone does not determine engine suitability or justify sharding. Preserve a simple deployment while measuring the write concurrency, working set and recovery needs that could change it.

Establish the actual environment

Inspect the application's database connection, not only the developer's SQLite CLI:

• Record SELECT sqlite_version(), sqlite_source_id();, the driver and relevant PRAGMA compile_options; output. Check runtime feature support before using version-dependent syntax.
• Identify file-backed versus in-memory storage, filesystem/mount location, number of processes, connection pool, journal mode, write volume and required durability.
• Inspect existing tables, constraints, indexes, triggers, views and migration history before changing them. Keep the repository's existing migration mechanism.
• Identify the accepted result or invariant, representative data, rollback/recovery approach and operation budget. Use available evidence; make missing assumptions explicit instead of inventing deployment facts.

For concurrent WAL use, compare the embedded build and any vendor backports with current SQLite release notes and WAL correctness notices. A recent CLI does not prove the deployed library contains a fix.

Define data and connection rules