Kadira: Shutting Down

Thanks for all your great contributions, this will be a big loss. I think MDG should pick up Kadira and provide it as a free hosted service, there is too much value in it and no real equivalent.


^ This.

Kind of a shame to see that no enterprising engineer has offered to step in basically ‘buy’ Kadira as a service.

I guess the real issue at hand is that the startups that used Meteor and would have been paying healthy sums for a service like Kadira, instead had enough investment $$ and enough FTE’s (that’s full-time engineers) to just completely build their own stacks and not continue using Meteor as it was for their companies.

Glad to see there are still people out there pushing it forward with stuff like redis-oplog.

Here’s to 2017 and hoping that MDG doesn’t lose focus on the magic that Meteor provides :slight_smile:

And to Arunoda - enough with the doom and gloom man! You built an incredible reputation for yourself and to this day I’m surprised that nobody managed to seduce you with a proper US Visa and a $250,000+ USD salary leading the engineering team at a startup. I can only imagine you have higher aspirations and for that, I salute you :slight_smile:


I think Kadira is an amazing product but they got pricing and market all wrong and that’s why it failed.

First, market. Meteor is used for tons of MVPs and smaller startups. This market is huge, it’s the cornerstone of Meteor’s success. Meteor Tools proves you can make a business out of that. But looking at pricing, Kadira focussed specifically on growth companies. There are not that many Meteor startups in that stage, so your market is really tiny.

Second, freemium startups have about 2-3% conversion, if you execute them well. This makes it extremely hard to be profitable. You get this immense overhead of non-paying users. Especially for something like Kadira which tracks events and results in huge amounts of data from free users. Not a very good decision.

Last, the plans were all wrong and obviously didn’t fit the market. Start at 19/month and you’ll be surprised what would have happened!

I think a pricing model like Meteor Tools is interesting for a lot of devs - instead of offering freemium.
I’d happily pay 100USD for a self-hosted docker Kadira solution, and pay again for future updates. And then when my company gets more serious, I’d probably go for a hosted managed version starting at 19-29/month and up.

So overall, really a shame to give up so early and easily!

1 Like

Even if they got rid of freemium and charged $5 a month for the basic tier. If you can get 1,600 developers who each have three apps they need accounts for, that’s almost 25k a month in revenue. MDG should think about offering it as a value-add service to a galaxy subscription… especially now they have 80% of the source code they’d need. It’d make galaxy that much more appealing than going the MUP route.

why not try and sell it? MDG didn’t want to buy it?


I totally agree Max. If MDG had bought this and incorporated it into Galaxy then it would overnight turn Galaxy into an incredible product. Not saying Galaxy isn’t already great but adding detailed performance metrics and server side error tracking would be brilliant. Great to see it’ll be available to run our own though.

Treading carefully around flame-war-inducing arguments, I’d like to point out a possibility that the reason behind MDG not acquiring, nor implementing a competitor to Kadira may simply be the same reason why Kadira is shutting down.

Meteor is evolving to align with the broader javascript vision and tools and converging its “data stack” efforts around graphql. And for graphql specific telemetry - where standard node monitoring cannot provide much value - they have optics.

Kadira was to Meteor what Optics is to Apollo.

And now that Meteor’s subscriptions are evolving into graphql queries and methods evolving into graphql mutations, monitoring pub/sub and methods is becoming irrelevant. Definitely in a year, if not sooner.

Then the rest of application monitoring can already be done - arguably better - with existing node monitoring tools.

That being said, I still see great value in pub/sub and methods for some apps, and for those apps, it is reassuring to know we’ll have some form of Kadira available, and that’s tremendously generous of Arunoda.


yeah makes sense, but sucks that Galaxy has no notion of error alerts by email, SMS, slack or any other method. Worth the price of Kadira just for the alerts.


Where did this information come from? Can you go into more details?

This is not information in the formal sense, but an educated guess judging by what’s all been going on with javascript, frameworks, meteor, graphql and apollo in general.

1 Like

@arunoda, Thanks for all the great work. And good fortunes on your future ventures! -Juan

I think Meteor is dying out and nothing to do with evolving of graphql


@arunoda great work and everything you have done, I wish you the best and looking forward to see what you do next.

Pub/sub = queries — yes
Methods = mutations ---- No

Mutations = update/insert calls only. Meteor methods can do any kind of business logic, and therefore not really equivalent.

Also with GraphQL monitoring is going to be even more important due to arbitrary complexity of queries. A single GQL query can return millions of records and hit hundreds of services! You’ll still need to profile them for performance, even more than pub/sub.

yeah we are also migrating away from meteor pub/sub to graphQL. Actually it’s very nice that our React components are all stateless. You can flip the data layer without rewriting your UI!

1 Like

How so? A mutation is a call to the server and whatever is called on the server can do anything, be it update/insert, send emails, call external api’s, heck, even reboot the server!

And that’s why MDG developed Optics, a somewhat counterpart of Kadira which is to graphql what Kadira was to pub/sub/methods.

Thanks @arunoda. Thanks for all your support.

GraphQL is a data api, and a mutation is a way to specify modifications to that data. I suppose technically you can write anything in the GQL server method which handles that endpoint, its like a stored procedure in a database. But that’s neither the spirit nor the purpose of the mutation.

This thread is getting off topic - please open new threads for specific discussions. Thanks Arunoda for all of the great tools! Some good ideas in this thread about future directions for the Kadira tool, we’re investigating different options and will provide an update soon.