Is there any feasible way to implement search client-side on a database of this scale?

I guess you would need some sort of search term to document id mapping that gets downloaded to the browser but maybe there's something more efficient than trying to figure out what everyone might be searching for in advance?

And how would you do searching for phrases or substrings? I've no idea if that's doable without having a database server-side that has the whole document store to search through.

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? :)

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'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.

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.

SRE here, Containers are not causing any performance problem.

Maybe the perception comes from all the Mac and Windows devs having to run a Linux VM to use containers.

Containers themselves don't, but a lot of the ecosystem structures around them do. Like having reverse proxies (or even just piles of ethernet bridges) in front of everything.

Or if you go ping pong across containers to handle a single request. That will certainly make a laptop unable to handle this load.