SQLite's Origin, Rigorous Testing, and Future

As a freelance developer in the late 1990s, Hipp disliked relying on a database server that could be unavailable and make his application fail. After a client contract ended, he built an SQL engine that worked directly with files on disk and released it as open source. Interest grew into paid support work, and by about 2007 he had a small team working on SQLite full-time.

Hipp says revisiting old code can feel like a time warp because he does not keep a clear chronology of events. SQLite uses a version control system he wrote himself rather than Git. Its website’s “This Day in History” feature shows past project activity, and Hipp has pledged to support SQLite through 2050.

SQLite has close to 100,000 handwritten test cases, according to Hipp. A customer in aviation introduced him to the DO-178B safety standard and modified condition/decision coverage, which he then applied to SQLite. He had hoped to sell test artifacts to aviation companies, but instead found that rigorous testing helped bugs subside.

As SQLite’s test coverage reached 100%, bug reports from Android dwindled, Hipp says. The broad test suite also lets the team refactor substantial parts of the code with more confidence. Running tests across many cores on Linux takes a couple of hours, and the team also tests Windows, Mac, ARM, x86, PowerPC, and Raspberry Pi, including on an old MacBook used for big-endian testing.