The Database Library Shipped

What it actually is

Not investigative research and not the design of this project's own storage. It is a compiled reference library, wired in through the sources: frontmatter of the database specialist's three consulting gates — the second-opinion checks that fire on access patterns, cross-engine compatibility and sync impact. That wiring is narrower than the shelf looks: five of the seven documents are named there, and the other two, operations and sync case studies, are cited by nothing today. So the role is precise — this research became the advisory material an AI reviewer consults when critiquing your database code, not a corpus every data lens reads.

A sample of what is in it

• Declaring a column STRING instead of TEXT silently gives it numeric affinity, so '007' becomes the integer 7.
• Over-indexing can reduce insert performance by up to 5×; a transaction-wrapped 100-million-row batch insert finished in 34.3 seconds against minutes per million done naively.
• At 10KB, storing a blob in SQLite is about 35% faster than filesystem I/O and uses 20% less disk.
• The sqlite3 command-line tool does not support parameterized queries — the largest single security risk in shell-script database access.
• Per-column CRDT tracking makes inserts roughly 2.5× slower with identical read speed; one sync product writes direct to Postgres and needs superuser, another routes writes through your own backend.
• Vector clocks are for fewer than about ten replicas; beyond that, hybrid logical clocks. EAV is demoted to a last resort.

The honesty note

This project's own SQLite configuration happens to match the library's recommendations almost exactly — foreign keys on, WAL journaling, a busy timeout. There is no citation linking them, and the repository even uses a different index-naming convention than the library recommends. It reads as convergent best practice, not as the library being the source. Claiming otherwise would be the easy version of this sentence.