Quirks, Caveats, and Gotchas in SQLite
Whenever comparing SQLite to other SQL database engines like SQL Server, PostgreSQL, MySQL, or Oracle, it is important first of all to realize that SQLite is not intended as a replacement or competitor to any of those systems. SQLite is serverless. There is no separate server process that manages the database. An application interacts with the database engine using function calls, not by sending messages to a separate process or thread.
SQLite Is Embedded, Not Client-Server
Some commentators say that SQLite is “weakly typed” and that other SQL databases are “strongly typed”. We consider these terms to be inaccurate and even pejorative. We prefer to say that SQLite is “flexibly typed” and that other SQL database engines are “rigidly typed”.
The key point is that SQLite is very forgiving of the type of data that you put into the database. For example, if a column has a datatype of “INTEGER” and the application inserts a text string into that column, SQLite will first try to convert the text string into an integer, just like every other SQL database engine. Thus, if one inserts ‘1234’ into an INTEGER column, that value is converted into an integer 1234 and stored. But, if you insert a non-numeric string like ‘wxyz’ into an INTEGER column, unlike other SQL databases, SQLite does not throw an error. Instead, SQLite stores the actual string value in the column.
Similarly, SQLite allows you to store a 2000-character string into a column of type VARCHAR(50). Other SQL implementations would either throw an error or truncate the string. SQLite stores the entire 2000-character string with no loss of information and without complaint.
Unlike most other SQL implementations, SQLite does not have a separate BOOLEAN data type. Instead, TRUE and FALSE are (normally) represented as integers 1 and 0, respectively. This does not seem to cause many problems, as we seldom get complaints about it. But it is important to recognize.