I'd like an open-source version and simpler pricing
I am considering using Convex in my next project as the feature set is close to what I will likely need and it will likely speed up development a lot.
However, I feel that I can't (and shouldn't) commit to building a business on a closed source/proprietary backend like Convex.
First of all, I feel I can't predict the pricing at all. I don't know how I could map the number of users to the 'function calls' and 'action compute'. I haven't started learning Convex yet so I have no idea what an 'action compute' hour is. And I don't want to waste time learning Convex because I don't know if the pricing model would be ok for me.
And what if my product is a freemium product where a large part of the user base uses it for free?
This pricing issue wouldn't be a problem if there was an open source version to fall back on that my company could run on our own if we grow big enough.
Or at least some kind of hosted plan that is more based on 'servers used' rather than uncontrollable (by us) metrics.
Even so, what guarantee do I have if Convex the company itself shuts down? What if I have thousands of business users relying on my app?
Picking a backend infrastructure technology stack is no light decision for a SaaS company. In Convex case it is both the backend compute and the DB, so it is even a bigger deal and these assurances are even more necessary.
Looking at showcases and projects that are using Convex, there seems to be only side projects and non-serious projects. I think one of the big reasons is probably above.
I have been bitten by choosing a relatively new DB (at the time) for a project before where the company shortly shut down. (It was RethinkDB.) Even though it was Open Source and development continues along by the community, it isn't anywhere near where it would expected to be.
Do you have anything that can assure me regarding these concerns above?
2 Replies
hi!
1. OSS and lock-in. We want to avoid the chicken and egg problem which might lead a company to under-innovate and adopt "standards" to avoid lock-in. So we've chosen to really innovate, but agree completely this brings up a real responsibility on our end to address lock-in with our customers. To that end, we fully agree there needs to be an open source option. And, it is underway right now! See our CTO's roadmap share out from November here: https://discord.com/channels/1019350475847499849/1019372556693815418/1169349065872519258 . There will be a self-hostable Convex backend soon. (Most of our effort will be into scaling up our SaaS offering, but we will have no problem if some customers choose to run their app in production on the OSS version and manage their own operations. [Note: Although we won't recommend it, as it will almost certainly be both less reliable, scalable, and more expensive except at very low scales.]) @nipunn is working on this project in earnest right now, but I'm guessing it's still a couple of months away. It's a really big job!
2. Serious projects -- there are several companies in production now on Convex (some with 10,000s of DAU), and quite a few (~15) companies in development right now that I imagine will go into production in early 2024. We haven't yet worked with these folks on creating "case studies" to augment the more self-share side projects showcases or hobbyist projects, but we plan on doing that in Q1 to help allieviate concerns about serious usage.
3. Pricing -- the pro plan attempts to have a simple pricing plan because it's really designed for teams developing an early app that want to have a "fixed" bill every month. There will most likely be a business plan at some point that does not include any built in resources, has a lot more line-items, and prices through compute resources more transparently. This would be more appropriate for teams with some real scale who are more concerned with the unit-economics of scaling their site rather than minimizing their monthly bill in the development phases of a project. That resource pricing will probably never be something like "machines" because you're running on vast pools of shared resources where the appropriate pricing is closer to something like GB-s rather than dedicated VMs. If we priced things in terms of VMs, Convex would end up being way more expensive, to be frank. In short though: it's convex's goal via architectural choices (automatic caching, etc) and team efficiency that it will ultimately be way, waaay more cost efficient for you to build on Convex than via a traditional stack
happy to expand on any of this or jump on a call if you want to hear more
Thank you for the answers! I think having a production ready OSS version would help a lot.
Great to hear about the companies in production on Convex