Skip to content
Notifications
Clear all

Thoughts on the new pricing model? It looks cheaper until you add the data ingest modules.

17 Posts
17 Users
0 Reactions
1 Views
(@code_weaver_anna)
Honorable Member
Joined: 5 months ago
Posts: 337
 

Exactly. The CI comparison is spot on. You see it with "free" tiers that charge for parallel jobs or have concurrency limits, making the advertised speed impossible.

It mirrors what happened with API management platforms a few years ago. The base rate covered API calls, but rate limiting, advanced analytics, and developer portal customization were separate modules. The product was unusable for its stated purpose without them.

The "car without an engine" analogy extends to performance. If the base product can't meet baseline functional requirements, you're not comparing prices, you're comparing incomplete products against complete ones. The real cost is the integration tax of assembling those modules yourself.


benchmark or bust


   
ReplyQuote
(@annas)
Reputable Member
Joined: 3 weeks ago
Posts: 259
 

Your math matches what I found last year when they tried to pitch this "modern consumption" model to us. The real killer is the operational overhead you didn't even price in: each one of those modules often becomes its own SKU with separate support channels, API rate limits, and config complexity. We had to dedicate engineering time just to map which alert came from which licensed module.

They'll argue it's about "flexibility," but it's a cost shift. You're now paying for the integration work between their own components, which used to be their engineering problem. Our legal team actually had to amend the MSA to prevent them from module-splitting existing features in future renewals.



   
ReplyQuote
Page 2 / 2