I've used Oracle, and other strictly-typed databases. Depending on the circumstances, that strict typing guarantee can be a godsend (mapping to C structs), or a roadblock (mapping from fully-general Python dicts). The ability to *choose*, at an *appropriate* level of granularity, *for the problem*, is nothing to sneeze at. It is important to remember, however, that *not everyone has the same problem!* STRICT could be defined at many levels of granularity: 1. Column level. You might make an individual column strictly INT, REAL, etc. 2. Table level, as described in the Draft. 3. File level. 4. Connection level. 5. Library level. As we go up the scale, each of these is usable in fewer and fewer cases. For example, one of my use-cases embeds a file's data dictionary (metadata) in the file. For the table of COLUMNS, which type should be used for the DEFAULT_VALUE column? That column should probably *not* be strict. But perhaps the table's other columns should be. And perhaps my application's tables, described in the data dictionary, should be strict, too. But perhaps only some of them would benefit. So it's important to choose a level of granularity wisely. Ideally, one that broadens SQLite's applicability, overall, rather than narrowing it. We see, from the above list, that the *scope* of the guarantee is one consideration. Scope, however, has multiple dimensions. One dimension is listed directly: size. But there are other scopes. For example: time. How valid is the guarantee if the current connection enforces it, and later ones do not? Another: the range of users. How valid is the guarantee if some apps' connections enforce it, and others' can't (or choose not to)? From what I can see, the Draft description is an attempt to craft a guarantee that you can reasonably count on, in a wide variety of circumstances, at a level of granularity that fits a wide variety of uses.