Provided that the web server is a layer over the database and doesn't handle much else (e.g. validation), is there a reason to use an asynchronous one?

The SQLite libraries and drivers in my programming language's ecosystem (Rust) are all synchronous, which is what led me to ask this question, but from what I understand, SQLite supports asynchronous reads. Would there be a performance improvement if the web server leveraged that, or can I shuck off the extra complexity and stick to synchronous Rust?

but from what I understand, SQLite supports asynchronous reads.

The sqlite3 C library (the component developed and supported here) is 100% synchronous, from top to bottom, with no asynchronous APIs.

What about WAL mode? According to the documentation:

WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.

Concurrent reads and writes implies you can execute multiple queries at a time, does it not?

From different threads within your app, I imagine. With each thread having its own connection and running synchronously.

Concurrent reads and writes implies you can execute multiple queries at a time, does it not?

You can, but that's a different usage of "async" than i parsed from your question. My comment was specifically about the "shape" of the C API: you do something and your call waits there until the answer is available. There is no part of the API in which you make a call, continue on your way, and then get an asynchronous response when the answer to that call is ready, arbitrarily far in the future. The latter is what most APIs mean by "async".

SQLite enables essentially an unlimited number of concurrent readers, and WAL enables a writer to function alongside those readers. This very site is backed by a db in WAL mode.