Larry's reply is likely applicable for many databases, but "even more so" for SQLite. The on-disk format of the SQLite schema is mostly just text (a master table holds the text of each table's schema). At startup, SQLite parses that text to build its in-memory representation of the schema. Reading and parsing that text takes time. Many other databases store a parsed representation of the schema. That may save some time at startup. If an instance of one of those database processes doesn't access some tables, that instance may never have to even get those particular tables' schemas into memory. If you are using a server-based database, you may be connecting to an already-running instance of the server. If "connect to server" is substantially less expensive than "connect to database", that would provide additional savings. The SQLite choice probably makes "Lite" easier to achieve. Clearly SQLite has to know how to read SQL. Reusing that knowledge at startup may mean writing less code specific to startup. There is also a good chance that the text-based schema makes backwards compatibility easier. Any structure that never goes to disk can be changed, without having to worry about maintaining code specifically to read the old version. I believe I've seen Dr. Hipp make similar statements, but I was unable to find those statements with a quick search.