> The great thing is that my blog is architecturally very simple, with all the content and images in an SQLite database that is live replicated with litestream.
What a weird definition of "architecturally very simple".
> 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.
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!).
> you prefer you program doing widely arbitrary and as such potentially dangerous things over it having a clean abort or proper error.
SQLite isn't a program, it's a library used by many other programs. As such, aborting is not an option. It doesn't do "wildly arbitrary" things - it reports errors to the client application and takes it on faith that they will respond appropriately.
> I suppose the encryption is only at the TLS layer?
Correct unless the fossil repository in question uses SQLite's SEE (encryption) extension (which fossil can, but relatively few repositories use that, AFAIK).
Back around 1990 my youngest brother, who had always seen CDs, asked me one day, "what are those things in your closet?" "What things?" "They look like CDs but they're big and black!" He had never seen a record before.
_You_ are using it right this second. It's storing your browser's bookmarks (at a minimum, and possibly other browser-internal data).
reply