I think the key thing here is the context and size; the searchable content of even a lot of e-mails is quite dense and small. I'm not a search expert but I'd look at precalculated indexes on very short substrings (3-4 characters maybe?), have the client pull those it needs for a particular query and then process client-side from there. (Doesn't even need figuring out in advance what people will search for, though that'd certainly improve things.)

I did say you pay with engineering, didn't I? :)

there's been demos of using SQLite client-side, with the database hosted in S3, and HTTP range requests used to only fetch the necessary rows for the query.

there might be some piece I'm missing, but the first thing that comes to mind would be using that, possibly with the full-text search extension, to handle searching the metadata.

at that point you'd still be paying S3 egress costs, but I'd be very surprised if it wasn't at least an order of magnitude less expensive than Vercel.

and since it's just static file hosting, it could conceivably be moved to a VPS (or a pair of them) running nginx or Caddy or whatever, if the AWS egress was too pricey.

Theoretically, just thinking about the problem... You could probably embrace offline first and sync to indexeddb? After that search would become simple to query. Obviously comes with it's own challenges, depending on your user base (e.g. not a good idea if it's only a temporary login etc)

There are several implementations of backing an Sqlite3 database with a lazy loaded then cached network storage, including multiple that work over HTTP (iirc usually with range requests). Those basically just work.