Isaac S.

neilay.mehta Sent you a dm!

Hi Isaac from the support team here. Did your partner send you an invite to join their organization, or a share link/URL for a specific database?

Hi Daniel W. glad you like them! The agents queries were simpler. They do a lot of poking around rather than writing big queries up front. That said, they can still write long nested CTEs when the question calls for it. We've seen that in benchmarks. Curious what's behind the question. Are you building something with agents, or seeing something odd in your own agent's queries?

Thanks for testing that, and glad it's working now. Your results show the download itself is fine, so it looks like Defender intercepted the first run. I'm not sure yet why it didn't trigger from cmd. I'm passing this on to our team to dig into. Let me know if anything else comes up!

Thanks for the details. One more thing that would help: downloading the install script to a file without running it. That tells us whether the download itself is being blocked or whether the problem only happens when it runs. 1. Open PowerShell (search "PowerShell" in the Start menu). 2. Paste this and press Enter: Invoke-WebRequest https://install.motherduck.com -UseBasicParsing -OutFile install.ps1 3. Then run these, one at a time: Get-Item install.ps1 | Select-Object Length Get-FileHash install.ps1 4. Send me the output of both, or a screenshot. This only saves the file and doesn't run anything. If you see an error, Defender pops up again, or the file isn't found, tell me what you saw, since that's useful too.

Thanks for the screenshots! Running it from CMD or another terminal probably won't change anything. You ran the right command, and Defender is flagging the command itself, not where it was run. I'm going to raise this with our team internally and will get back to you as soon as I have something. In the meantime, a bit more context would help us narrow it down:

If you can, also send a screenshot of the entry in Windows Security > Protection history for this alert. And I'd hold off on re-running the install command until we've taken a look.

Hi Abir M., thanks for flagging this. To help us investigate, could you share a few details? 1. The exact command you ran (copy/paste is perfect). For example, was it the MotherDuck install command from our docs (`irm install.motherduck.com | iex`), the DuckDB one, or something else? 2. The domain the script was downloaded from. That's the part of the URL right after https://, like install.motherduck.com or install.duckdb.org. We just want to confirm it came from us. 3. The exact name Defender gave the detection (something like Trojan:Script/...) and which file it flagged. A screenshot works too. Until we've figured out what happened, I'd hold off on re-running the script and leave anything Defender quarantined as is.

Hello André M.! Following up with a correction to my earlier reply. I ran a proper repro: it's network round-trip time driving this, not catalog rebuilding. Each round trip costs ~75ms. Catalog size contributes but isn't the main driver; a 400x larger catalog only added ~26%. Did you get a chance to try the persist_docs changes, or find another way to cut those times down?

André M. Happy to help! COMMENT ON COLUMN replaces that table's catalog entry and bumps the database's catalog version, which leaves the client's cached catalog stale. The client rebuilds the full catalog every column write. With no multi column form, that's 20 rebuilds for 20 columns. The transaction helps because in auto-commit, each statement needs a second round trip to fetch the new catalog. In a transaction the server sends it along with the statement itself which saves a roundtrip per comment. The rebuilds still happen per statement though, which is why you saw an improvement rather than it collapsing to a single commit. For now, if you have persist_docs enabled, setting columns:false keeps your model-level descriptions while dropping one statement per column. If you want to keep column-level descriptions, scoping them to your marts and leaving them off staging may help: docs.getdbt.com/reference/resource-configs/persist_docs The rebuild cost should track the size of that database's catalog rather than the comment itself, so it'd help to know which database you benchmarked against and roughly how many tables it has. Let me know if anything's unclear. I'll see what more we can do on our side and get back to you.

Sahil G. Hello! We've fixed this issue in our latest release. Can you confirm on your end that you can hit close without zooming out, and that the Guides pop-up X's out while the upload modal is open?