After two years, 8,000+ commits, 50 releases, and amazing feedback from thousands of developers, Convex just released version 1.0. It's our first generally available long-term supported release, and we’re proud to say it’s the most productive and enjoyable way to build a backend for your full-stack app.
Check it out:
If you’re in a hurry, just go try it now. We’ll wait:
But if you want the back story on what we built and why, read on.
Convex is the result of being fundamentally unsatisfied with the existing experience of backend engineering, and the willingness and experience to rethink everything about how backends are architected, written, and operated.
This might sound like a crazy undertaking, and admittedly it is. But after a journey of lessons and realizations, we've grown to believe that it can and must be done...
Peer pressure as a service? Pivot!
By 2020, the Convex founders had spent almost a decade designing, implementing, and operating some of the industry’s biggest infrastructure services at Dropbox. So naturally, when we ran off to do a startup together, we had visions of making the world’s greatest… social self-help app?
Hey, it was the heady “no-bad-ideas” days of the company, and a lot of the projects under consideration were good ol’ consumer-facing apps that simply felt fun or meaningful to us.
So after compiling our list of wild ideas and apps, it was time to prototype a few and see how they felt. We were newly free from the complexity of a 13-year-old infrastructure at scale (still ♥️ you Dropbox), and consequently quite excited to be able to use the “modern cloud” all the kids had been raving about. Surely now we’d be in pure bliss, building our projects at the very speed of thought!
But no actually. This stuff still sucks. For example, when I’m making my self-help app, why do I need:
- To know the difference between ECS, EKS, Fargate, and 14 other AWS services that run code for me?
- To choose “compute optimized”, “memory-optimized”, or, I suppose, “un-optimized” instances?
- To once again write at least two layers of coupling between (my app → my server-side edge API), and (my server-side controllers → my database)
What does any of this shit have to do with helping me people eat less red meat?
We gritted our teeth and moved on. Then a few weeks down the road, we were chatting with other founders in our network. We showed off a few of our demos and asked them about their startup’s biggest challenges. They all kept complaining about building infrastructure, and we kept agreeing. Then, one particular founder got more direct and shook us out of our fog:
Them: My saddest day was the day we outgrew Firebase and I had to start building out backend engineering and DevOps again. Just doing the same, undifferentiated glue stuff every other technology company is also doing. None of this has anything to do with my product.
Us: Yeah, I know, right? That is really frustrating.
(awkward pause)
Them: Aren’t you all, like, experts at that stuff? Could your startup be fixing that? Like Firebase that will go the distance?
Us: Well… Um. That actually makes sense.
And the seed of Convex was borne.
Assess the patient
The first goal was to figure out why backends suck. Clearly, very smart people have worked long and hard on server-side software. After a lot of soul-searching and conversations with all the software people we knew, this is what we concluded:
There are a lot of venerable technologies that were born and refined over decades out of specific narrow (but deep) academic traditions. They are treated as invariant and so our job on the backend is not to have the audacity to change them, but to respectfully glue them together. (The most venerable of the lot? The database.)
Effectively, this gluing together of those venerable primitives means that the backend is designed bottoms-up. The problem is the frontend frameworks are designed top-down to make it as easy as possible to write software to serve the needs of the user. One group reveres the user, and the other reveres Michael Stonebraker. And when these two different architectural paradigms collide, one can use this handy flow chart to make progress:
These adapter layers when two design philosophies collide are a classic source of technical boilerplate. Code just to glue one thing to another.
And there’s a lot of it. Consider, ignoring the frontend for a minute, even within backend engineering, these independent, venerable systems each have slightly different philosophies for architectural design and configuration. So our backend itself is full of tons of adapting and type/paradigm mapping layers to make each system transit, represent, and manage data in its own way. Full of boilerplate.
We’re so surrounded by it, we treat boilerplate like gravity–an inevitability. It’s not! But we need to choose a unified design philosophy to eliminate it.
Tiebreaker time: backend or frontend architectural philosophy? It might seem like a nuanced decision, but we've come to believe it's quite clear.
Chad Maycumber
Founder & CEO at Stealth AI Startup
"Convex has not only eliminated a vast amount of boilerplate code from our system but has also greatly improved the developer experience within our organization, thus, enabling us to deliver products more swiftly. I would highly recommend Convex to any team looking to streamline their coding processes, optimize developer experience, and expedite product development."
Fine. Let’s make a top-down infra system
Replacing all those powerful, complex backend architectures with a focused new platform is impossible, right? I mean, there are so many different kinds of jobs to do.
Actually, not really. What do we really need backends to do?
- Store and retrieve data for us with consistency and correctness
- Give us some mechanism to know when data we depend on has changed
- If it’s an app interested in the change, it might update its UI
- If it’s a server-side job interested in the change, it might take action–let's call this workflow
- Allow us to run jobs in the background, on demand, on timers (crons), or on records matching some predicate (batch migrations and so on)
- Provide various ways to index this data (search, vector, traditional b-tree) so our app stays fast as our data grows
- Give us a connection to the outside world to integrate its data with our own
- … and that’s kind of it
This isn't actually a very long list. Backend architecture gets so complex because of the emergent complexity when coupling the preexisting components to accomplish these jobs. But the app itself has few truly unique needs from the backend.
RJ Dellecese
Founding Software Engineer at GlobeCommerce.co
"Convex has re-imagined from the ground up what the primitives of an application platform should be, and are delivering on this vision with admirable rigor and comprehensiveness. Convex offers just about everything that a serious, modern software product might need to be successful, all carefully designed and fully integrated on a single platform. This is really not the stringing together of isolated offerings that you're used to—it's clear that every Convex feature is added with intentionality, and fits together/interoperates coherently. The resulting DX is truly unparalleled!"
Real-time is all the time
Why the hell should anyone ever have to hit F5? Why should we ever have to poll to see if data has changed? Why should the app ever be responsible for its own caching? Doesn’t the database know the data changed? It committed it! Why won’t it tell anyone?
It might be surprising to hear this is a high-level conviction for us. But we’d argue that developers are so used to apps being non-reactive and used to reactivity so painfully opt-in that we have too narrow a view of the applications. “Real-time is only useful if I’m making an app that needs to update right away. This app doesn’t.”
As we’ve built Convex, we’ve discovered something else side by side with our customers: ubiquitous reactivity means no more cache management, no more query retries, and immediately iterative development cycles. When everything is reactive by default, it changes the way you think about application architectures. Whole classes of state management problems go away.
Now, the only thing we need is modern apps written in a way that’s super compatible with reactive backends. Oh, they are now? Thanks React! 🙏
So in Convex, we built “the Reactor”. A reactive database living in the core of our platform that enables universal, automatic data reactivity. When data changes, it does the neighborly thing and actually lets interested parties know.
Allen Hartwig
CTO at Gated
"Convex’s React-first design makes it an easy decision for the vast majority of modern applications. The ability to go from schema declaration to realtime, reactive querying and view rendering in a matter of seconds sets it lightyears ahead of the competition. Eliminating the need to think about state management, pagination patterns, refetching logic, etc, reduces the surface area of my problem space to differentiators of my product instead of the technicalities of today’s frontend stack."
Be the tortoise, not the hare
There have been so many compelling new ways to manage server data introduced to the tech ecosystem over the last 15 years. The most compelling among them, however, always cut architectural corners that lead users to resent the platform a few months down the road. Inevitably, these “hackathon heroes” eventually send developers scrambling back to those glued-together venerable old backend architectures as the grey beards gleefully crow “I told you so!” from the sidelines.
To go the distance, a new backend platform must very carefully balance the tradeoff between a magical week one and a magical year two. We’ll admit, we always want new users! But we will not create a great first-week experience that will leave you feeling cheated by Convex as your project grows.
Inside our team, we talk a lot about the “pit of success” we want our developers to find themselves falling into over and over again where things keep working out better than expected. We obsess over this pit of success. But we’ve learned it takes a diligent adherence to values to make sure the pit of success keeps widening. Some of the big ones:
- There have to be rules for where data changes and where it doesn’t. Just as React has pure render trees, hook rules,
useEffect, and so on, Convex also requires developers to follow some structure around where data changes and where it doesn’t. Who mutates and who reacts? How should we handle side effects? The benefits for code organization and project composition as your codebase grows are worth it! - You need ACID transactions, and you need relationships. A hierarchical document database without relationships is not enough. Neither is a non-transactional key/value store. CRDTs are definitely not enough. We’ve tried them all on real projects! In our experience, every project and company eventually needs true ACID transactions. So just accept it and optimize for it out of the gate.
- Conflict management and concurrency control are the platform’s responsibility. To us, conflict management is the very epitome of complications app developers don’t really want to spend much time dealing with. So while the platform design needs to allow ACID transactions, it must do it in a way that conflict management and concurrency can just be handled automatically, without any explicit involvement from the app developer.
- Scaling is the platform’s problem. You shouldn’t have to think about how to partition your data, or how your data architecture will need to change as your app grows. The platform needs to be designed with scaling in mind and cannot commit to magical day-one experiences that cannot scale.
- Expose low-level primitives and higher-level composition. Magical high-level abstractions are great until they suddenly can’t express what you need. Then you’re stuck. So in Convex, the built-in primitives in our platform are quite low-level: they’re just TypeScript functions! Over time, we’re shipping higher-level capabilities like middleware, ORMs, and integrations with 3rd parties as open-source libraries built on these few primitives. That way developers on our platform are never stuck, and can always take apart, rebuild, or customize these higher-level abstractions to fit their specific needs.
- Freedom and discipline both have merit. Sometimes you just want to chuck records into a table and figure it out later. Sometimes you annotate types when it’s useful, but write it like plain ol’ JavaScript when you’re moving fast. However, the day may come when you want to solidify your designs. Convex, too embraces this concept of gradual rigor. For example, you can operate schema-free as you’re iterating, and we’ll keep track of all your records' types for you. But we also let you lock in a schema and type enforcement when you’re ready–heck, we’ll even generate your schema for you!
- We will not be your everything. As wonderful as we hope you will find Convex, we know it will not solve all your backend needs. Modern apps integrate data from lots of different systems and API services. We want to be the foundational layer for your app, but not the totality of it. That means we need to include excellent support for streaming data in and out of Convex, for merging data in from outside APIs, and so on. These features are table stakes.
- You will see our chisel marks on your chair. Convex is a work of engineering, but it’s also a work of choices, tradeoffs, and of commitments. You will sense the craftspeople on the other side of the product–our team, our product values, and the way we intend to grow ourselves and our platform. There is no glossy sheen that hides the humans from your view.
If you’re nodding along with most of these values, then we’re pretty sure you will love Convex.
Seth Raphael
CEO at Hello Wonder
"These days, realtime collaboration and communication are table stakes, every product is expected to nail it. Convex makes it drop-dead simple to handle the crazy-hard backend to make it happen, and I get to focus on making a magical user experience. As a front-end dev, I’ve always dragged my feet when I needed to write some server code. Now with Convex, I can dive right in with the confidence that my code will run well and scale!"
And here we are
Convex 1.0 is the manifestation of these convictions in the form of a product. And it’s ready today to help you build your next full-stack company or project with as much ease and joy as possible.
We would like to extend a huge “thank you” to our users and customers for betting on us so early. And deep gratitude to our amazing team for building a shared vision with us and executing on it with such passion and ownership.
Up next
We have a long list of improvements we’re planning on shipping in the next few months:
- New built-in features like authentication and AI-specific features like vector search
- An open-source self-hosting option
- Sophisticated telemetry and monitoring for production Convex projects
- More powerful data export options
- SOC-2 compliance
If there’s something you’d love to see on that list or discuss with us, join our discord community and come talk to our team!
