dbt

have a new pricing model. It is part seat based, and part model materialisation based. I can’t help but think that

dbt

have viewed Dagster’s pricing model and taken inspiration from it. As it is now almost a mirror image in terms of structure (per seat + per model/materialisation). Dagster still provides waaaay more model materialisations per month at the same $100 team price mind you. But Dagster has a significantly higher learning curve, setup and overhead for companies out there who are “just”

dbt

houses. But that overhead cost comes with the advantage of incomparable flexibility. So we can’t have our cake and eat it too 🙂 I’m still not a fan of this pricing approach. It kills smaller companies who have small (in terms of run time / compute), but frequent, materialisations. Larger companies with similar setups can eat the cost. But smaller ones can’t. Alas, I thought it was an interesting paralel.

Hey @Todd de Quincey thanks for the thoughtful note: Re: the learning curve for dbt shops. We’ve been focusing on getting the onramp smoother for that customer set. Please check out this tutorial. Specifically we have a one-liner to “dagster-ify” a dbt project. See that section here. With regards to pricing this is always a challenge. As I like to say, if infrastructure SaaS were a video game, pricing is the final boss. The truth is the economics of an intensive infrastructure product are difficult to make workable without usage-based pricing. Even though we are the control plane, you would be surprised at our resource costs and how they scale with usage. We also spin up isolated resources per customer for reliability and fault tolerance. We’ve attempted to make this scale down to as many small teams as possible with both a “user bundle” as well as a “credits bundle” for our team SKU. We also endeavor to make our platform powerful, flexible, and very reliable so that customers feel like they are getting a ton of value out of the product.

Hey Todd! Thought I’d throw in my feedback, for what it’s worth. Nick nailed it, onboarding DBT within Dagster has become so much easier. The Dagster DBT NUX guides you straight through the process. You get an example DBT project once done to learn off of before you decide to wipe it clean. Your DBT orchestration is all built in with the example provided. You just uncomment the schedule, set your interval and you’re off. This brings your costs down to Dagster Cloud as DBT would be running as DBT core, not cloud. I haven’t tested the costs for DBT models being materialized, so I don’t want to misspeak when comparing the two here. I cover some of this in my blog if you’d like to read. I shared it in the #dagster-showcase channel.

I think my post has been misinterpreted a little. Perhaps I convoluted it with the side comment of not being a fan of the approach (that was intended to literally be a side comment). The main point was to highlight that dbt has a similar pricing model now. Which is an interesting evolution and perhaps, in a way, is validation for Dagster. In hindsight, perhaps this post was better suited to the random channel. As it’s not feedback, just something that I found interesting. I’m not in the boat of finding it hard to onboard dbt in Dagster. I have an engineering background. It was more a consideration for people with a heavy analyst / analytics engineer background who may find Dagster harder to get setup with. If that learning gap has been plugged then that’s excellent!