well D1 is just SQlite so I would assume it'd be fine if they got it working with sqlite there, there is some additional security restrictions (like with query/etc anti-abuse limits) they use that have cropped up in the past but I think they've eased up on a lot of them
There's also a few commands that are restricted in D1 vs regular SQLite for security reasons (some of the PRAGMAs) but yeah, otherwise it's pretty similar.
D1 can't connect via the MySQL protocol at all, so the second part wouldn't really be a consideration - you'd need to just adapt the commands to be proper SQLite queries before sending to D1.
If you mean connecting to actual MySQL from Workers then I believe there were some efforts to get some of the MySQL drivers to work with the Workers TCP Sockets API.
think your best luck if you really wanted to throw some time away is to take the work they did there to get local sqlite working and hook up their translated queries up to a worker just proxying the query/results
if you wanted to actually run wordpress itself on workers that's a whole different beast lol, I know people got php working (wasm compiled, not just transpiled iirc) but not sure about the rest, Workers have a size limit of 10 mb and a startup limit of 400ms which can be a bit bothersome
Depends on how you want to do it. Workers are short lived, part of the problem. If you wanted to actually run php/wp on workers establishing a websocket for each incoming request to another worker/durable object I think would be more expensive then just simple queries (espec if you can batch them into a few)
if you were going to do wp on an actual server you could use DOs to keep the websockets alive/sleep them, maybe more efficient to keep them open long term
sounds like a mess eitherway though lol, D1's cool for a lot of things, espec if we get read replicas, but WP is its own beast with the amount of queries it can make espec with plugins, not natively supporting sqlite even, and trying to run it is a whole different story
Wouldn't want to deal with added latency of API defeating much of the purpose.
A DO with hibernation seems okay as long as nothing about websockets makes it rly bad. Assuming the mysql lexer can relatively painlessly be ported to typescript or rust even, and then take some mysql proxy code (Of which there must be plenty) and slapt that in there. Better yet something like this would be an accelerated start running alongside wordpress (Or whatever): https://github.com/novnc/websockify
as it is right now a D1 database is only in a singular location, no read replicas yet and only where Durable Objects are supported https://where.durableobjects.live/
yeaaa would have to adapt to the web js environment, or hope there's enough node compat to make it work if it was just largely based on buffers and such, could potentially steal a good chunk of it
a rust mysql/sqlite lexer parser doesn't feel like a lot of overhead. websockets to a worker doesn't either but D1 not being replicated is a nonstarter. I will relent. For now, the dream is dashed.
a lot of overhead vs not doing it and just having a local DB instead/replicating a local DB. It might make sense for some simpler things once Read Replicas come out, but WP is a ton of queries, ehh