Why does Google Chrome use SQLite if the usage of threads results in parallel access?

Question

I don't know much about how Google Chrome or SQLite works, but I know that Chrome makes heavy use of threads (I think a thread per tab). Additionally, I know that SQLite suggests to use a client-server database if parallel access is required. I'm not sure, but I assume Chrome uses SQLite like Firefox does, to save cookies.

Therefore, I think it's quite likely that parallel access to the database happens (because every Tab needs the ability to save cookies).

Therefore, it doesn't make sense to me why Google Chrome uses SQLite.

• CodesInChaos: Saving cookies is a rare operation, so the cost of thread synchronization doesn't matter much.
• thorsten müller: You will normally only use one tab at any given time even if you have opened hundreds. Also there is not that much writing going on and tabs rarely share the same data. So not much risk of conflicts.
• uuu: why the downvote?

Answer 1

Because SQLite is a simple self-contained library, and because most SQLite databases (on an Android tablet or Google Chrome computer) are very probably accessed by only one (or a few) processes or threads at a time. (Accessing or saving cookies happens rarely in a browser, probably at most on each page reload, and they are probably also cached in the browser).

The alternative would be to require these systems to have an always running DBMS server (e.g. PostGreSQL, MariaDB, MongoDB or something else). This might be a burden, and is adding a new single point of failure and perhaps more security & reliability concerns (a leak or failure in the DBMS server might impact every application; some heavy SQL request might slow down the DBMS so impact other applications; etc...).

At last, there might also be licensing issues (perhaps Google lawyers prefer the SQLite license to the MariaDB one...).