Convex State of the Union

It's time we gave a little “state of the union” update on Convex and where we’re trending. The high level is that we’re pretty happy with the Convex API right now so the current swing within the company is to focus more on scale and polish for a while, with the caveat that we have some big features already in the works that are coming out soon.

Features

Our Head of Product Indy has been giving regular product updates on Discord and via email, including our recent launches of native Swift and Kotlin libraries. Soon we’ll have a better backups feature that runs on a schedule and is stored server-side. We also have deep integration with TanStack Start which not only provides excellent SSR support but also exposes a bunch of new developers to Convex.

I want to call out two big features specifically because I think they’re pretty core to how the platform is evolving:

Local dev

We’re getting bigger customers and some are seeing code sync times take up to a minute. That’s not good! We’re always working on speeding up bundling and sync but sometimes you just want to iterate really quickly on a local backend. We already have an internal branch that supports running dev deployments locally. Once we’ve had a bit more time testing it we’ll get it in your hands.

Components

We’re going to have a huge release tomorrow to announce Convex Components — drop-in modules that act like services but execute within the same transactional context as the caller. You can think of these like talking to a third-party service but where you don’t need to reason about data staleness or inconsistency, as life should be as a Convex developer.

Initially we think folks are going to be happy to have a bunch of new features, like a geospatial indexing component, or a Twilio component, or an aggregates component. Having components built on top of Convex will allow us to move faster and add new features without changing the core of the platform.

Eventually we think the main value prop for components will be modularity. Large companies don’t scale their orgs by having everyone write to the same shared set of tables. They build APIs that abstract away the underlying details of a service, which is exactly what components provide. You’ll be able to write your own components and use them to structure your apps.

Scale and Polish

We’re not thrilled about some of the availability incidents we’ve had recently and are excited about putting more effort behind hardening the platform in a few key areas:

Polish

There are some rough edges in Convex that could do with a bit more love. One is built-in auth, which had more gaps that we’d like but is rapidly getting better. Team management on the dashboard is also getting better. We’re adding better insights for when you should be adding an index or tweaking your queries. Overall we just want to make Convex “feel better” to use.

Infra scale

We’ve been spending a bunch of time redesigning our internal architectures to support more customers, larger customers, and higher workloads. None of this has been particularly surprising and is going as planned, but it takes a fair bit of work. We’ve also been improving our uptime: some folks would have experienced recent dashboard and code sync outages, which should be significantly less likely now. We’ve also greatly reduced the impact of internal database failovers, which happen with close to zero downtime in most cases.

I’m always happy to talk more about scaling but we’ve built plenty of large systems before and this is kind of our bread-and-butter. We just need to do the work.

Logical scale

There are some problems you can’t just scale your way out of. Sometimes a workload just has too many users writing to a set of document in a way that’s not possible to handle in a serializable way. This shows up as OCC conflicts or scheduled functions falling behind.

Every now and then I chat with a database person who tries to say that “serializability doesn’t scale”, which is a funny perspective because Convex provides serializability as a baseline guarantee, it doesn’t mean you have to do everything in your app synchronously.

Sure if you have a million visitors per second all trying to update a single document there’s no database in the world that can handle that load synchronously. This is why Convex provides support for asynchrony and this is an area we’re going to invest a lot more in:

• Probably you’re already using scheduled functions to trigger work that doesn’t need to happen immediately. This is a powerful pattern for designing chained workflows, especially because scheduled functions are durable, just like a database transaction.
• We’ll release a workflow component which packages scheduled functions up into a Temporal-style workflows where you can specify long-running flows that span multiple functions.
• Sometimes you get an influx of API requests that you don’t want to handle all at once and instead want to queue them up and process them over time. We’ll be releasing a workpool component that you can just throw your scheduled jobs into and it’ll process them at a given rate.
• Sometimes you want to maintain a counter or aggregate over a huge number of users and don’t want them all contending over a single document. We’re releasing a sharded counter component that packages that up for you.
• Sometimes you’re building a service that doesn’t need to update its state immediately and instead wants to buffer up changes to apply in batches. That’s a great use-case for a component that writes state to a buffer table and then uses a scheduled job to process it, all hidden behind the component API boundary.

With components, scheduling, and our transactional guarantees, I believe we have a development model that will scale for the lifetime of an application, while being highly ergonomic and conceptually clean.

What we’re not working on right now

Given our current priorities there are a few important features we’re not working on. The big one is built-in OLAP support. We were going to release a new primitive for long-running analytics queries directly on your Convex database but have deprioritized that for a while. It’ll be done eventually but in the meantime you’ll have to stream your data out to an analytics db.

We’re also not immediately redesigning pagination or optimistic updates, although we’d like to do both of these as soon as possible. We think we can improve our API aesthetics here plus rethink optimistic updates as more of a “local store” that works more seamlessly with offline mode.

Philosophy

We’re quite proud to say that while many loudly-echoed architectural trends have come and gone in the lifetime of Convex, our perspective has remained relatively unchanged. We want this to be the simplest, most elegant, and most thoughtful way to build applications. We think these are the right abstractions that developers should be using and are the same primitives we’d be using for our applications if we weren’t here building Convex.

You’ll start seeing more messaging around sync and Convex being a “sync platform”. This phrase is hot right now but we’ve actually called our web socket protocol our “sync protocol” since the dawn of Convex. Jamie has a great article on this he recently published. In many respect sync is the right way to think about the relationship between a client app and the backend.

Sync is also related to the local first movement that’s getting a lot of attention recently. “Local first” can mean a lot of things. If it means that end users should have a great low-latency experience with end-to-end consistency and support for offline mode then we’re all on board. We’ll make improvements to our optimistic update functionality and turn it more into a local-store/offline-mode feature. If “local first” means that the default development model for app developers is to spread their source of truth all over the world and then somehow try to reconcile all that inconsistency on the backend then we think this is not the right starting point for most applications. Sujay and I talk a lot more about this with TomR on the most recent Databased episode.

On the topic of Databased, if you have any requests for stuff you’d like for us to talk about let us know! We’re iterating on the format but always want to keep it sincere, informative, and to reflect our personal convictions not just whatever happens to be hot on twitter today.

Thanks for being part of the Convex community and helping advance the state of application development!