> SQLite runs in the calling process, so if Racket runs there, SQLite will
> too.  It's not like other SQL databases that have to run as separate
> daemon processes.
Not sure if I understood what you mean but it's less about processes and
more about storage. Container platforms tend to shy away from SQLite
because it needs to use an ordinary file as a backing store. Each
container usually has an ephemeral file system (can be rebuilt from
scratch at any time). This is the reason why e.g. Heroku doesn't support
SQLite. It's a sane approach to distributed systems because it forces
one to use a data store with a well-defined interface (with respect to
consistency, access control, backups, replication, etc.)

Maintaining an external data store like that would normally be
over-engineering for a use case as simple as ours, but not when a
platform provider like Heroku or AWS makes one with the click of a
button. It's simpler in every way to use SQL than to use files on
Heroku. This is bonkers when coming from a classical Unix background,
but natural when considering that databases have always been built with
a view to the consistency and replication concerns of distributed
systems, whereas file systems have been shoehorned into that role late
in the game.

For file storage these container apps tend to use services like Amazon
S3 that offer the data model of a versioned file system with the
consistency and replication guarantees of a database.

Docker lets you poke a hole in a container's ephemeral file system so
that a directory of your choice accesses part of the "real" file system
of the underlying Linux server, but this is going against the grain of
container platforms. On a small-time server it's mostly fine (e.g. poke
a hole for SQLite so the DB file is stored outside the container).

Apologies if you knew all of this already :)