37 ms·
> I have a python web app that creates a DB connection per request (not ideal I know) FWIW, "one per request per connection is bad" (for SQLite) is FUD, plain
by sgbeal 1y ago
> I have a python web app that creates a DB connection per request (not ideal I know)
FWIW, "one per request per connection is bad" (for SQLite) is FUD, plain and simple. SQLite's own forum software creates one connection per request (it creates a whole forked process per request, for that matter) and we do not have any problems whatsoever with that approach.
Connection pools (with SQLite) are a solution looking for a problem, not a solution to a real problem.
- benhurmarcel 1y agoWhere can I read more about this? I use connection pools with SQLite, I’m interested if I can simplify.
- sgbeal 11mo ago> Where can I read more about this? There's nothing specific to read about it, just plenty of anecdotal evidence. People use connection pools because connecting to _remote_ databases is slow. SQLite _is not remote_. It's _in-process_ and _fast_. Any connection-pool _adds_ to the amount of work needed to get an SQLite instance going. It's _conceivable_ that pooling _might_ speed it up _just a tad_ for databases with _very large schemas_ because parsing the schema (which is not done at open-time, but when the schema is first needed) can be "slow" (maybe even several whole milliseconds!).