SQLite's STRICT tables, introduced in SQLite 3.37.0 (November 2021), enforce rigid typing by rejecting invalid data on insert or update. Adding STRICT to a CREATE TABLE statement prevents text from entering INTEGER columns and blocks bogus column types like GARBAGE, DATETIME, or UUID. Only INT, INTEGER, REAL, TEXT, BLOB, and ANY are permitted, and columns must declare a type. The ANY type preserves flexibility for columns that genuinely need mixed data.

Strict tables catch errors early — inserting 'garbage' into an INTEGER column fails immediately rather than silently succeeding. Lossless conversions like the string '123' to integer 123 still work. This mirrors type enforcement in other SQL engines and eliminates a class of subtle bugs caused by unexpected data types.

Migration is the main drawback: existing tables cannot be altered to STRICT; data must be copied into a new strict table, which fails if invalid data exists. The SQLite team disagrees with strict-by-default, documenting advantages of flexible typing for key-value stores and messy CSV imports. They consider non-strict tables "legacy" in source comments but defend the behavior officially.

Performance impact appears negligible. The author tested millions of rows across 100 columns with no measurable difference in speed or disk size. For new projects, strict tables provide meaningful data integrity with minimal cost.