[HN Gopher] DBT Cloud increase Team plan price by 100% and limit...
___________________________________________________________________
DBT Cloud increase Team plan price by 100% and limit features at
the same time
Author : unklefolk
Score : 88 points
Date : 2022-12-15 17:13 UTC (5 hours ago)
(HTM) web link (www.getdbt.com)
(TXT) w3m dump (www.getdbt.com)
| pbowyer wrote:
| 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.
| Aeolun wrote:
| 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?
| scosman wrote:
| My 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.
| dijit wrote:
| > Also: don't use Mailchimp.
|
| Noted.
|
| Alternatives that you rate?
| Aeolun wrote:
| I switched (back) to Sendgrid and I haven't needed anything
| else since.
| scosman wrote:
| 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.
| podoman wrote:
| checkout https://loops.so
| jerrygenser wrote:
| 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.
| AnEro wrote:
| 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
| Ftuuky wrote:
| We use at this company the open source dbt for multiple teams,
| all bigger than 3, just fine.
| tehalex wrote:
| 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.
| oxfordmale wrote:
| 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.
| pixiemaster wrote:
| [deleted]
| datalopers wrote:
| What is their cloud offering if it's just sql templating? Why
| would anyone pay for that?
| tehalex wrote:
| 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...
| moltar wrote:
| 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.
| purpleblue wrote:
| 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?
| Phelinofist wrote:
| 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.
| ccn0p wrote:
| 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".
| thenipper wrote:
| > "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...
| [deleted]
| FlyingSnake wrote:
| I have seven words for you: "I...love...goolibib's integrated
| multi-platform functionality!"
| unklefolk wrote:
| 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.
| nerpderp82 wrote:
| 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?
| cristiandima wrote:
| 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.
| muraiki wrote:
| 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.
| schipplock wrote:
| who?
| nodesocket wrote:
| wpietri wrote:
| I can see two reasons to make a comment like this. One, you
| think that there is somebody here who has not heard of the free
| market before. The other is to preempt criticism of a material
| change in pricing. Neither makes any sense to me. One can't
| have free markets without free speech.
| nodesocket wrote:
| wpietri wrote:
| Then what's the point of your comment? Did you sincerely
| think that somebody here didn't know that markets work
| through customers deciding what to buy?
| tshaddox wrote:
| Also "free market" doesn't mean "you don't get to make any
| value judgements about any decisions made in the market."
| Quite the opposite, in fact.
| beckingz wrote:
| 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.
| vorpalhex wrote:
| 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!
| dennisy wrote:
| 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...
| thenipper wrote:
| You know you can self host it if you need to.
| CompeAnansi wrote:
| Yeah, don't trash that work. Just use DBT core instead. You can
| call DBT runs from Airflow jobs quite easily.
| richwater wrote:
| > 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.
___________________________________________________________________
(page generated 2022-12-15 23:01 UTC)