by unklefolk on 12/15/22, 5:13 PM with 53 comments
by scosman on 12/15/22, 9:09 PM
- 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.
by oxfordmale on 12/15/22, 8:18 PM
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.
by AnEro on 12/15/22, 6:04 PM
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
by thenipper on 12/15/22, 6:30 PM
Give me a break...
by unklefolk on 12/15/22, 5:13 PM
by jerrygenser on 12/15/22, 6:23 PM
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.
by cristiandima on 12/15/22, 9:42 PM
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.
by maximilianroos on 12/16/22, 1:30 AM
- 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.
by beckingz on 12/15/22, 5:57 PM
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.
by vorpalhex on 12/15/22, 5:57 PM
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!
by pbowyer on 12/15/22, 9:50 PM
From the other comments it's clearly popular but I've never come across it in use.
by tehalex on 12/15/22, 8:34 PM
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.
by blakeburch on 12/16/22, 3:49 PM
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...
by slotrans on 12/15/22, 11:04 PM
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.
by richwater on 12/15/22, 10:10 PM
My sides. Give me a fucking break.
Also, forcing any group who wants more than 8 licenses onto Enterprise? Laughable.
by purpleblue on 12/15/22, 9:57 PM
How many months from now will there be a "I take full responsibility for these 25% layoffs" email?
by kaustavm98255 on 12/16/22, 10:24 PM
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.
by roeja on 12/16/22, 1:01 AM
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
by karakanb on 12/16/22, 3:31 PM
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.
by ccn0p on 12/15/22, 7:46 PM
by dennisy on 12/15/22, 7:52 PM
Also Google have their own version of this, which for those who are using GCP and BigQuery could mean an easier which…
by Phelinofist on 12/15/22, 7:45 PM
by schipplock on 12/15/22, 8:26 PM
by moltar on 12/15/22, 9:37 PM