Disclosure: I'm from Datacoves, we run managed dbt Core, so we have a horse in this race. Wrote this up because the license change is confusing and we had to untangle it for our own customers.

The short version:

One engine now. dbt Core v2 and Fusion share the same Rust runtime. Core v2 is Apache 2.0, fully open source. Fusion is the enhanced proprietary distribution on top of it.

Fusion is the recommended default, and it's a funnel. Free to install, and the new license lets anyone offer it as a managed service, as long as you don't block the path to a dbt Labs account. Free login unlocks advanced features, paid platform account unlocks premium ones. Reasonable model, but go in with eyes open.

Metered pricing is inside the dbt Core now. dbt State (skip models when logic and data haven't changed) bills $0.094 per model reused per day. Orchestra open-sourced a free alternative (Sao Paolo, Apache 2.0).

Migration gotchas: every deprecation warning must be resolved before v2 runs your project. Python models don't work in Fusion yet. Community adapters are constrained (drivers need to be signed by dbt Labs). --models and -m error out, --partial-parse is gone.

The afternoon test: upgrade to v1.12, clear deprecations, run dbt parse --use-v2-parser. Tells you where you stand without committing to anything.

Full writeup with a Core v2 vs Fusion comparison and the four ways to handle state: https://datacoves.com/post/dbt-fusion

Has anyone run the v2 parser against a large project yet? And is anyone planning to use dbt State or trying out Sao Paolo?

Every time snowflake cost optimization lands on me it comes down to the same couple of boring things. Credits were up a good bit this quarter, finance flagged it and it wasn't more queries or more users. Usage barely moved.

Went through query history and it was mostly one warehouse that a BI tool kept awake almost all the time because auto-suspend was set to 3600 seconds instead of 60. Whoever set that has left. Two other warehouses were sized a couple of steps bigger than the work ever needed.

Dropped the suspend and resized the two big ones, that part was easy. What I keep going back and forth on is how far down you can size a warehouse before it starts hurting, because too small and the queries just queue and run longer and you give the savings straight back.

Where do you draw the line on warehouse size and are you catching the auto-suspend stuff as it happens or only when the bill jumps?

Hello :)

I am currently setting up a Cortex Agent with the aim of using the Cortex Analyst to address complicated text-to-SQL/business questions.

At this point, I would like to establish common limitations of the orchestration budget with regards to the following factors:

– Tokens;

– Seconds.

The Snowflake solution has recommended a time budget of 5 minutes, which was unexpected.

At the moment, I am estimating something of around:

Budget: tokens: 16000, seconds: 300

The objective is primarily to protect against any unusual long reasoning or looping that would lead to unnecessary costs while avoiding rejection of valid questions.

To those who work with Cortex Agents on a day-to-day basis:

What limitations do you normally apply when setting tokens and time?

Do you use fixed limitations or determine precise limitations on the basis of the actual usage, such as P95 + certain margin?

Also, what experience do you have regarding reliability of the mechanism when applying time limits below 5 minutes?

Thanks for the feedback !