enabling WAL helps a lot as it allows concurrent reads and a write
@receiver(connection_created) def configure_sqlite(sender, connection, *kwargs): if connection.vendor == "sqlite": cursor = connection.cursor() cursor.execute("PRAGMA journal_mode = WAL;") cursor.execute("PRAGMA busy_timeout = 5000;") cursor.execute("PRAGMA synchronous = NORMAL;")
Initially, I was worried that Django might screw up migrations since it's a bit awkward to make certain schema changes in SQLite. Also almost no one seemed to use SQLite with Django in production, so I was a bit worried about how battle tested the SQLite part of the ORM was.
So far so good.
Your configuration looks right to me.
> I asked Django Fellow Carlton Gibson what it would take to update that advice for 2022.
Glad to see that SQLite is being presented as a valid option in the current version of the docs.
> Even without WAL mode, bumping the SQLite “timeout” option up to 20s solved most of the errors.
Can you say anything about the tradeoffs when increasing the timeout, maybe in the context of Django?
My hunch is that if you bump it up to 20s while receiving a huge amount of concurrent traffic you may find yourself running out of available Python workers to serve requests.
It seems to me like they removed the warning on SQLite, so I guess they tested it and it works fine. But I didn't research this any further so far.