Prefer strict tables in SQLite

316 points · 161 comments on HN · read original →

Points and comments are a snapshot, not live.

Strict tables in SQLite enforce rigid typing to prevent datatype errors.

SQLite's strict tables, added in version 3.37.0 (November 2021), enforce rigid typing at table creation by appending STRICT. They prevent inserting wrong types (e.g., text into INTEGER columns) and reject invalid column types like GARBAGE or DATETIME. Only INT, INTEGER, REAL, TEXT, BLOB, and ANY are allowed. Flexible ANY type preserves backward compatibility. Disadvantages include inability to alter existing tables to strict (requires data migration), potential performance overhead (the author found no practical difference), and incompatibility with older SQLite versions. The author prefers strict tables despite SQLite's documented preference for flexible typing.

What commenters are saying

Many commenters agree strict tables should be the default, citing backward compatibility as the reason SQLite hasn't changed it. Some defend flexible typing as useful for key-value stores or CSV imports. Commenters note SQLite's dynamic typing derives from its TCL origins and dbm storage. Several criticize lack of a proper timestamp type and foreign keys being off by default. One commenter suggests using ANY for audit tables where flexible types are needed.