Como "várias gravações simultâneas" é muito mais difícil de realizar no mecanismo de banco de dados principal do que o de um único gravador e vários leitores. Está além dos parâmetros de design do SQLite, e incluí-lo provavelmente subverteria o tamanho e a simplicidade deliciosamente pequenos do SQLite.
Suportar altos graus de simultaneidade de gravação é uma característica dos grandes mecanismos de banco de dados, como DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL e Sybase. Mas é tecnicamente difícil de realizar, exigindo amplo controle de simultaneidade e estratégias de otimização, como banco de dados, tabela e bloqueio de linha ou, em implementações mais modernas, controle de concorrência multi-versão . A pesquisa sobre este problema / exigência é volumosa e remonta a décadas .
O SQLite tem uma filosofia de design muito diferente da maioria dos DBMSs centrados no servidor que suportam vários escritores. Ele foi projetado para trazer o poder do SQL e do modelo relacional para aplicativos individuais e, na verdade, para ser incorporado em cada aplicativo. Esse objetivo requer trocas significativas. Não adicionar a infra-estrutura significativa e a sobrecarga necessárias para lidar com vários escritores simultâneos é uma delas.
A filosofia pode ser resumida por uma declaração em uso adequado do SQLite : p>
SQLite does not compete with client/server databases. SQLite competes with fopen().