Con el desarrollo de SQLite 4, el énfasis se está poniendo fundamentalmente en mejorar su rendimiento. Es una consecuencia lógica debida a su mayor popularidad, que la han hecho evolucionar como backend de datos de aplicaciones cada vez más complejas.

Hasta ahora, los esfuerzos se destinaban sobre todo a añadir nuevas funcionalidades, al mismo tiempo que mantenían el código lo suficientemente compacto, como para correr en plataformas con recursos hardware limitados.

En este sentido, algunas opciones de compilación nos permiten añadir funciones que por defecto no están activas tales como SQLITE_ENABLE_FTS4, SQLITE_ENABLE_RTREE o SQLITE_ENABLE_STAT4; mientras que otras, nos dan la oportunidad de mejorar su rendimiento: SQLITE_TEMP_STORE 2, SQLITE_THREADSAFE 2 y SQLITE_ENABLE_ATOMIC_WRITE.

Sin embargo es habitual que trabajemos con versiones precompiladas de SQLite, ya sea desde WebSQL, sobre las que no tenemos control en cuando a compilación. Para ello, el sistema nos ofrece ciertos PRAGMA, que permitirán ajustar su comportamiento en tiempo de ejecución, y así, mejorar su velocidad de ejecución.

Es interesante comprobar:
PRAGMA journal_mode=MEMORY;
PRAGMA journal_mode=OFF;
PRAGMA synchronous=OFF;

Por supuesto, como buena constumbre, forzar el purgado, el reanálisis, y el reindizado cada vez que abrimos la base de datos, o preferiblemente cada vez que la cerremos, evitará que las prestaciones se degraden a medida que haya movimiento de datos. Os podéis dirigir a:
VACUUM;
ANALYZE;
REINDEX;