sqlite A field note by Vikrant Sharma
SQLite stores null bytes in strings without warning
SQLite will happily store NUL characters in text columns. Your application layer might truncate them silently.
SQLite treats NUL bytes as valid string characters. Most other databases do not. PostgreSQL throws an error if you try to insert a string with \0 in the middle. MySQL silently truncates at the first null byte. SQLite stores the whole thing.
This matters because C-style string functions stop reading at the first NUL. If you pull a SQLite string into Python or JavaScript, you get the full value. If you pass that same string to a C library, it sees only the characters before the first \0.
The SQLite documentation calls this out explicitly. They note that the length() function counts bytes, including NULs. The char() function can insert them deliberately. There is no built-in way to strip them.
I have seen this bite log parsers. A malformed UTF-8 sequence gets written to a SQLite events table. The parser reads it back, passes it to a regex engine written in C, and the match fails because half the string disappeared.
The fix is to sanitise on write or wrap every read in a check for \0. Neither feels clean. SQLite is embedding-friendly by design, but this is one place where that flexibility creates a trap.
If you are building a system that stores user input in SQLite and then hands strings to native libraries, check for null bytes at the boundary. SQLite will not stop you. Your segfault handler will.
