That's a useful pointer, thanks. And it's half true of my setup. Ordinary queries already go through send, because I needed cancellation, so a SELECT against md: is on the async path. But my connect sequence is one multi-statement query call: INSTALL, LOAD, SET token, ATTACH 'md:' together. Because prepare won't take multiple statements, and ATTACH is the remote one. That's exactly the shape you're describing, and it runs at sidebar startup where a hang is least recoverable. Same for any multi-statement user query, which falls back to query for the same reason. Something to fix in the next release. Would be curious whether you've seen the deadlock on ATTACH specifically, or only on remote SELECTs. It would tell me how far to take the split.
Good to know, thanks. I checked my logs: 0.6.6 is the version I evaluated for COI, and I carried that conclusion forward without retesting the client. Then recently I probed the 1.5.2 extension release directly and found it loads fine without isolation. I just hadn't joined that up with the client tracking the same extension versions. The requirement was never really the package's. It was the extension build underneath it. Sticking with the extension route regardless, for a reason that has nothing to do with isolation. The whole point of the add-on is joining MotherDuck against local files and spreadsheet ranges in one query, and those are registered in the DuckDB-WASM instance the sidebar already runs. Installing the extension into that instance keeps it to one engine. A separate client would be a second engine that can't see any of it.
I’ve integrated MotherDuck into SQL Cell, a Google Sheets add-on I’ve been building. You can query MotherDuck tables from the sidebar, profile the result, and write it back into the sheet. One use case I’ve found especially useful is joining a table in MotherDuck with a small mapping table maintained in Sheets. The warehouse has the data, while the spreadsheet has the business-specific context. You can combine both in the same query. A note for anyone attempting something similar in a constrained frame. An Apps Script sidebar is a sandboxed iframe inside docs.google.com, so it is not cross-origin isolated and never can be — COOP/COEP belong to the top-level document, which is Google's. That rules out motherduck/wasm-client, which needs SharedArrayBuffer. What does work is the motherduck extension installed into the DuckDB-WASM instance that was already there: INSTALL motherduck FROM the version-keyed repo, LOAD, SET motherduck_token, ATTACH 'md:'. Both api.motherduck.com and ext.motherduck.com send permissive CORS headers, so an arbitrary origin is fine. It fails on the v1.4.3 extension build and works on v1.5.2+. The engine version was the whole story. Thanks for shipping a build that loads without cross-origin isolation. It's the reason this exists at all. The result profiler borrows your Inspector's layout, since it turns out to be the right one: a row per column with type, a distribution silhouette, and either a range or a cardinality. It runs SUMMARIZE against the materialised result rather than the source, so profiling a query incurs no additional network overhead. Anyway, very happy to finally have MotherDuck working inside Sheets. Here is the marketplace link workspace.google.com/marketplace/app/sql_cell/178915154116
I was experimenting with a tower defence game where you place towers on a grid using SQL. Apart from that, there are hardly any game mechanics that utilize data tools concepts. Alternatively, it could be a spinoff of SQLPD.
Saw a puzzle game featured in codepen's newsletter -- Ducky Fog. Remembered you're into 🦆 https://codepen.io/Pedro-Ondiviela/full/JjqKWNp
.png){kind=logo}
