DBT Cloud increase Team plan price by 100% and limit features at the same time
getdbt.comMy take on raising prices (ran this playbook twice now, once at my company, once with a company I'm an angel in):
- Grandfather in old users for as long as you can. Forever if it's feasible. More than likely future customer revenue >>> current customer revenue so it's not worth burning goodwill. Don't go past this point unless you have a really good reason.
- If you absolutely need to increase prices for current customers, the warning should be long (6mo+). If people want to leave, they shouldn't feel rushed, and they should have time to put migrating off on their roadmap. More time also helps goodwill.
- Give several automatic extensions of ~1 month after initial deadline. No matter how many times you email, some people won't read them. This has a few benefits. 1) extensions help pick up some users who would have churned. They might miss deadline 1, but you can pick up an extra 10-15% on an extension. 2) It give you something to point to when the price increase hits and they contact support ("we told you 4 times, and extended it twice already"). It's not perfect, but it helps. Be sure to send an automatic email when you extend. 3) People will leave it to the last minute, and migrating off might take longer than planned. Blanket extensions reduce the number of panicked manual extensions, and lower manual support load.
- Be willing to give a manual extensions of a fixed time for those who raise a stink to support. Messaging can be "we'll give you a 4th extension of 3 months, but this is really the last one". Let the support team grant these without any approval to lower management overhead. It makes most people happy, but more importantly, it spreads out the anger over a longer time.
Ultimately, the steps above will slightly increase uptake, but dramatically reduce the chance of ending up on the front page of hacker news. The latter is more important, it's burning chances with future customers.
Mailchimp's Mandrill is still the worst case I've ever seen. Cheap to host product, increased prices dramatically, with minimal warning, no opt in, and unsympathetic tone from C-suite. People don't forget when companies act like this. Also: don't use Mailchimp.
> Also: don't use Mailchimp.
Noted.
Alternatives that you rate?
Since it was price driven we went with AWS SES. We were high-volume low-value per email. A high-value low-volume use case might have better options. I’ve heard good things about sendgrid. Someone who gives a damn about delivery rate.
Can’t recommend SES. We have someone nearly full time managing the suppression list. We don’t even spam. These are just system notifications that the users need.
I switched (back) to Sendgrid and I haven’t needed anything else since.
checkout https://loops.so
In a recession you learn who your true strategic partners are. It is fair enough that prices need to be increased in line with cost, however, a 100% increase with one month notice is #@#**. In our case it would be a 600% increase as this forces us onto the enterprise plan. Budgets for 2023 have already been agreed this late in the year, so this is a hard sell to the C suite.
Our conclusion is that we can't rely on DBT cloud. What is stopping them from doing this again next year?
DBT is a great tool, however, in the end it is just a Ninja templating engine. I have build something similar myself in the past, and for now I can just use dbt-core with VsCode.
What is their cloud offering if it’s just sql templating? Why would anyone pay for that?
Most people will just use the sql templating and scheduled cron jobs features of the cloud, which is very easy to self host.
There is cloud IDE, which is just ok in my opinion. I'd rather use a local editor, but might be a value add for some.
The cloud plans also has metadata features and APIs, which could be worth it for some use cases.
The most interesting thing tied to the cloud is the new metrics feature, but I don't really like how it's done (metrics are defined as sql fragments in YAML). Really using metrics depends on proprietary parts that dbt cloud only has, so if you are using this, you'll probably be paying for the cloud.
[1] https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sema...
I'm not a fan of the IDE myself, but I knew a few people who are less technical and prefer the IDE over managing a local python environment.
The cloud offering makes development easier for analysts, that are good at SQL, but not necessarily familiar with tools like VSCode. It is worth $50 per developer seat, however not $100 and definitely not $600 if you are onto the enterprise plan. For the enterprise, there are discounts available, however there is a high risk they won't be available in a in years time.
Only reason I'm kinda okay with this is because of the open source side is still strong. It's 90% of the features needed for a product, but the cloud offering is the same 90% but better for teams bigger than 3 and larger organizations.
I genuinely think that this pricing increase is justifiable, and also will spark more competition to DBT Cloud's features in the open source space to get select cloud features. Since they are objectively forcing out a large amount of small teams and start-ups
For instance, I was planning to organize the data side of my consulting side there, but it doesn't make sense to do that anymore. So if someone's doing that now, it Christmas is gunna be fun switching over to your own solutions
We use at this company the open source dbt for multiple teams, all bigger than 3, just fine.
Oh I just meant you actually start getting value at a team size of 3, not that once 3 people touch a repo it's unmanageable lol
> “Drew and Connor and I came to that decision with literally zero analytical rigor—we just wanted to unlock the analytics engineering workflow to as many humans as possible”
Give me a break...
I have seven words for you: "I...love...goolibib's integrated multi-platform functionality!"
Price will go up from $50 to $100 per seat. Now can only have 8 seats instead of 40 seats and only 1 project instead of unlimited projects.
Charging on a per-project basis puts an arbitrary distinction on how customer's should structure their work. I thought we were over having the top level folder structure be a driver for pricing?
Long time dbt user since early days, 2018. I started on git ci/cd and orchestration or runs via airflow. I'm sure there are even easier ways to do it these days.
I'm hoping the silver lining is that more of the "less technical" business folks referenced in the announcement who were willing to pay $50/seat but not $100 will actually upskill, set up their own orchestration and development process, and end up not paying dbt together.
I appreciate the no bs hn submission title, it made me click the link just so I can read and laugh at the PR approved title.
I was not disappointed: “Updating dbt Cloud pricing to support long-term community growth” - though I reckon they could have gotten “journey” in there as well.
This made me laugh..
“We actually get community members reaching out to us concerned that we are under-charging them because they want our business to be successful! “
May be it’s true but it’s beyond me that people are asking for a price increase??
I'd be sympathetic to that pitch if it was a one-person passion project, and the increase was from $5 to $10, but a whole company going up that much? No.
lol, they actually put it as a zinger at the end of the announcement:
> Thanks, as always, for being a part of this journey.
I have to say, the tone and execution of this announcement has killed all interest I had in dbt. I don't want to have to explain company behavior like this to my boss when proposing the use of a new tool.
While the timeline is rushed and the explanation is disingenuous, the sentiment here is way too reactionary.
- dbt has made a huge impact on the data ecosystem. It's made data engineers' lives way better, speaking from experience. It's so central that most new data tooling builds on top of or integrates with dbt.
- The core product is completely open-source, they have dozens of people working on it.
- It's good for the world if open-source companies can be profitable! We should want more of that. The overflow from open-source is much bigger than closed-source companies.
- It's good for the world if they can stay independent — getting acquired by e.g. Azure would be a decent exit for them, but would balkanize the ecosystem.
- dbt cloud was fairly cheap relative to competitors — something like Looker is multiples more expensive.
I wish Tristan had written "We need to increase our prices — we've had a huge impact on the space but don't yet have a reasonable path to profitability. And we're cheaper than these 5 comparable services!" rather than "isn't this great for you all". But they deserve a bit of leeway given their contributions.
It is only the timeline I have a major problem with. If they had given us 6 months notice it would allows us to either negotiate a larger budget with the C-suite or migrate to a cheaper solution. With one month notice we are being held hostage. That doesn't take away from the fact that DBT is a great product.
Based on the public posts I've seen about enterprise prices, for many teams this will mean a 600%+ per seat increase if they have more than 8 developers.
Which makes sense because dbtLabs has a bunch of venture funding and is trying to monetize their community and open source package, but is rough for organizations that want to encourage their analysts to move towards engineering levels of quality.
One of the reasons they want to increase price is because they have new features.
Yet not every customer uses every new feature. Indeed, features are often used to bring in new customers. Sally wants eg live metrics, Bob needs a specific kind of weekly report.
Now Acme co wants to increase the price to both Sally and Bob since there are more features, but Sally and Bob each only use a single feature.
The other issue is that two critical features for dbt are under more expensive plans - SSO and api access. This sours the lower plans by quite a bit. Even as a solo dev, I use SSO!
Also it feels like trying to have it both ways. Increasing your spending to get new features is the model of non-subscription software. And if people don't think it will make enough difference, they won't buy upgrades for years.
When you're paying a significant monthly fee, you're already paying for a supply of features and refinements.
Can someone do a better job than the dbt homepage and explain what this is and _why I would need it?_ The pictures show SQL being generated using a templating language - when do I want that?
From the other comments it's clearly popular but I've never come across it in use.
ELT approach means you copy raw data from transactional sources, events, external APIs and dump it in the first “layer” of your data warehouse.
Then you progressively clean it and model it into some format that is easily usable for dashboards or self service analytics.
To do that you build a DAG of SQL scripts and dbt makes that easy through templating, macros and automatically generated docs.
You still have to execute the DAG somehow and here you either use their OSS version and schedule it with anything from Github Actions to Airflow, OR you buy their Cloud offering
I guess it’s a way to stop former dba’s and etl people from just storing their queries/stored procedures all over the place?
It’s (mostly) for data analytics teams, not software engineers.
They use it to transform raw data in their data warehouses into views/tables that people can use for analysis.
It is, for me and my team, a framework for building out and maintaining a data warehouse much like Rails is a framework for building out a web app.
We had to abandon DBT cloud because it was very feature limited - it does the basics well though, so is a good starting point for most, but seems like it's easy to outgrow.
The new metrics feature is tied to DBT cloud - probably because that is the only way they could get bigger users to get value from their hosted product and not just DIY it. (offering a largely propitiatory feature). However, I don't know what the uptake of the metrics feature is - it seems half baked to me.
At what scale have you decided you’ve outgrown it?
What was the dbt replacement?
One of the main benefits we hear from people using dbt Cloud is the IDE + scheduler. The price increase can make that main benefit a bit less palatable, especially when you can develop locally and orchestrators allow you to run more than just dbt itself.
If you're looking for a way to quickly automate dbt Core, our team at Shipyard (low-code, cloud-hosted orchestration) recently built out some guides to start running dbt Core in the Cloud for all of the major databases. Plus, you gain the ability to connect to other tools in your data stack, run Python scripts alongside dbt, and still not worry about infra.
Text Guides: https://www.shipyardapp.com/docs/data-packages/dbt-core/dbt-... Video Guide: https://www.youtube.com/watch?v=wdbEiPHfKS4&list=PLsy6kuGU_w...
DBT is a good (not great) tool, but DBT Cloud just doesn't provide any value, much less enough to justify $100/seat.
Unfortunately the business is doomed unless they can come up with a new business model. Two friends work there so I take no joy in this.
> We actually get community members reaching out to us concerned that we are under-charging them because they want our business to be successful!
My sides. Give me a fucking break.
Also, forcing any group who wants more than 8 licenses onto Enterprise? Laughable.
Doubling prices in the face of a recession, especially where tech companies are cutting back is undoubtably a company-killing decision.
How many months from now will there be a "I take full responsibility for these 25% layoffs" email?
Disclaimer: I am working on an analytics operating system on top of dbt, and we have overlaps with dbt cloud.
I think dbt is a great tool but such a significant price increase at this time of the year + forcing people to upgrade to Enterprise, on a product that is quite feature limited, is quite draconian - reminded me of the 90s IT software selling.
I have heard time again from data leaders how the dbt cloud price-value curve is broken - very little product updates & hefty price increases. As y'all have been saying, I think some of the options going forward are:
1. You can cut down your dbt-cloud seats and move people to VSCode (Cost: $100k+/yr) - zero tool cost, but very high time & FTE cost to build and maintain.
2. You accept the price hike and increase your budget (Cost: 100 - 600% up, likely no budget left for 2023)
3. Migrate to alternatives such as paradime.io (up to 70% cheaper) - and you get a fuller platform covering 80% of your daily analytics work + Looker / Tableau integration, Github apps, CI/CD etc.
If anyone is interested, I am happy to demo what we've been building.
Having deployed DBT Core I am glad I spent the effort to set up self hosting with ci/cd for both dbt runs and docs.
A point of frustration I have is the idea that Data Analysts need a specialized cloud based ide to work in because vscode and git is too difficult to learn. I worked at a large company where analysts would complain the database was down due to the cloud ide falling over and stop work until it is fixed. Meanwhile the group of us using a local ide and a jdbc connection kept working.
Any good data analyst should be able to use vscode and git. Any good data engineer should be able to setup the ci/cd side to the point for the analyst doesn't need to think about deployment.
Analyst writes code -> creates pr when ready to test -> pr builds models into temp location and runs tests -> analyst iterates -> pr review -> merge to main -> deploy to prod runner
Disclaimer: I am working on a competitor that can also run Python, on a closed beta period yet.
It is an interesting choice to increase the prices with such a short notice indeed. The cloud business for DBT is competing with its open-source version, and utilizing dbt-cloud could mean a nice inconvenience, one that can be exchanged with a steep, sudden increase in prices. In the end, what dbt does can be replicated within the existing environments the customers have along with dbt core, e.g. running them in Airflow. This might be happening because of the pressure their business is getting inline with their recent investment rounds and valuation.
If anyone is interested in an alternative, I'd be happy to share what we are working on, the link is in my profile.
all just part of building a sustainable business in a rapidly shifting climate from "growth at all costs" to "break even as fast as possible".
I am using DBT and I think this is quite unfair, mainly because we have recently introduced this and have built on it quite a bit. Removal of DBT is now a big job, so I think using this knowledge and doubling prices does not seem fair.
Also Google have their own version of this, which for those who are using GCP and BigQuery could mean an easier which…
Yeah, don't trash that work. Just use DBT core instead. You can call DBT runs from Airflow jobs quite easily.
You know you can self host it if you need to.
Never heard of DBT before so can't comment on that. However, I think the decision to do the increase at once seems kinda "fair". I mean they could've just raised by 10 every year were most people might say "oh it's only 10 bucks, so no big deal..." till they creepingly hit the 100 as well. At least they are upfront.
who?
If anyone wants to self host a robust dbt workflow on AWS - dm me. I have a solid infra as code (AWS CDK) solution that accounts for a lot of functionality, including hosting generated docs.