Last week we announced SpacetimeDB 2.0 and with it our entrance into the web development space. If you're not familiar with SpacetimeDB, it is a database which also functions as your server. We originally developed SpacetimeDB as the backend for our MMORPG BitCraft Online because it dramatically simplified our development. Although some of our customers used SpacetimeDB to develop web apps, it was not originally a major focus. Our primary focus was performance for our own game and our customers' games and applications. Now in 2.0, we are committed to providing the best web development experience possible.
As part of our keynote, we highlighted SpacetimeDB's excellent performance with a benchmark that we feel clearly demonstrates just how much performance is being left on the table with the existing web architecture you would find in 99% of web applications. We showed, for example, that in this benchmark SpacetimeDB is nearly 1000x faster than Convex, and roughly 10-100x faster than most other common web app setups. The Convex team's reply was quite measured, but essentially boils down to "benchmarks don't matter, we're fast enough for our customers". While the article suggests that benchmarks are often apples-to-oranges, this benchmark is very much apples-to-apples as SpacetimeDB provides the same ACID guarantees as Postgres or Convex, and in some cases even greater guarantees.
Although our philosophies on the importance of performance and what it means for users differs greatly, Convex provides a spiritually quite similar product, and their article is absolutely correct in suggesting that performance isn't the only requirement for happy customers. It's not even the most important thing. And Convex, I must admit, nails a lot of the most important things.
So today I want to do something a little unusual and tell you why you should choose Convex over SpacetimeDB.
Why am I writing this?
I have enormous respect for what the Convex team has built. They are tackling the same fundamental problem we are, and in many areas I think their product currently beats SpacetimeDB. I think pretending otherwise would be dishonest, and I think our community deserves honesty more than they deserve cheerleading.
More importantly, I think that both SpacetimeDB and Convex represent the future of how software will be built, and I'd rather we lift each other up than tear each other down. The real competition isn't between us. The real competition is against the old way of doing things: the sprawl of microservices, the duct-taped WebSocket layers, the prayer-based consistency models, and the general misery of modern backend infrastructure.
So let's talk about what Convex does really well.
1. Components and integrations
Convex has built an impressive component system that lets you drop pre-built, sandboxed modules into your backend like npm packages. Need Stripe integration? npm install @convex-dev/stripe, register it in your config, and you've got checkout sessions, subscription management, webhook handling, and real-time payment queries all wired up with transactional guarantees. Need rate limiting? There's a component for that. Need a collaborative text editor backend? There's one for that too.
The component library spans AI tooling, authentication, durable functions, geospatial queries, file storage, and integrations with services like Resend, Twilio, Cloudflare R2, and more. Each component is sandboxed so it can't accidentally mess with your application's data.
We don't have anything like this yet in SpacetimeDB. We think composable, reusable backend modules are a great idea (especially ones that work across programming languages!), and it's something we'd like to build toward, but Convex is shipping this today.
2. LLM developer experience
The Convex team has been remarkably deliberate about making their platform work well with LLMs. They maintain a public LLM leaderboard that benchmarks how well different models generate correct Convex code, they've built a rigorous evaluation suite called Convex Evals, and they provide curated AI rules files for Cursor, Windsurf, GitHub Copilot, and other IDEs.
We have our own LLM benchmark page and we provide llms.txt files as well. But I think Convex has invested more deeply here, particularly in the systematic evaluation of LLM performance and in providing guidelines that measurably improve AI code generation quality (they report roughly a 20% improvement with curated guidelines). They've also built an MCP server that gives AI agents direct access to Convex deployments.
LLMs build on top of Convex and SpacetimeDB remarkably well. Guarantees like reducer/mutation atomicity and automatic real-time synchronization make it substantially easier for both LLMs and humans to build what they want with fewer bugs. The Convex team, I think correctly, realizes that better integration with AI tools means that you can learn the platform and build what you want faster. Gone are the days that you need to scour the docs just to get started. We are also investing heavily in this direction, but Convex's support here is first-rate.
3. Node.js compatibility
Convex actions support a full Node.js runtime. You add "use node" to the top of your action file and suddenly you have access to the entire Node.js ecosystem. This is a pragmatic and useful escape hatch for calling third-party services, using Node-specific libraries, or doing anything that doesn't fit neatly into a sandboxed runtime.
SpacetimeDB does not yet support this, so the go-to escape hatch is to create a separate "side-car" Node.js service that interacts with SpacetimeDB as a special client. We think of this as SpacetimeDB "failing-safe" to a regular server/database setup. It's always possible to use Node.js, but a separate service is, I will admit, decidedly less convenient.
4. Convex Chef
Chef is Convex's AI-powered full-stack app builder. You describe what you want in a prompt, and Chef generates a complete working application with a Convex backend, authentication, and a React frontend. The clever part is that Chef typechecks the generated backend code and feeds errors back into the LLM, creating a self-correcting loop.
This is a genuinely great way to get started. Instead of reading documentation and setting up boilerplate, you just describe what you want and get a working app that you can then download and customize in your IDE. It's the kind of thing that dramatically lowers the barrier to entry for new developers.
We don't have an equivalent tool, but it's unclear whether it's worth the effort given that people often prefer to use their own agent programming tools like Cursor, Claude Code, OpenCode, or Codex. As LLMs continue to improve, less and less guidance and bespoke tooling will be needed, but that doesn't mean it's not useful today.
5. Agent API
Convex has built a thoughtful agent framework as a component. It provides abstractions for agents, threads, and messages, with persistent storage, hybrid vector/text search, tool calling, and streaming over WebSockets. Because it's built on Convex's real-time infrastructure, agent interactions get delta-based updates over WebSockets rather than HTTP streaming, which is a meaningful improvement for building responsive AI applications.
It also includes workflow support for multi-step operations that survive crashes and retries, usage tracking for billing, and rate limiting to keep you from blowing through LLM provider quotas.
SpacetimeDB's architecture is actually well-suited to this kind of thing (persistent state, real-time sync, and transactional guarantees are exactly what you want for durable agent workflows), but we haven't built the framework yet. Convex has.
6. Webhook support
Convex supports inbound webhooks through HTTP Actions. You define routes in a convex/http.ts file using a familiar Fetch API-style interface, and you can receive webhooks from Stripe, Clerk, Twilio, or any other external service. They also support integration with Hono for more sophisticated routing and middleware.
SpacetimeDB currently doesn't have webhook support as of today, although it is a top priority. Many practical applications need to receive notifications from external services, and right now you'd need to build a separate service to handle that and bridge it into SpacetimeDB. We know this is important and we're working on it, but today Convex handles this out of the box.
7. JavaScript support and gradual typing
Convex lets you write your entire backend in plain JavaScript without TypeScript if you want to. You can start with no schema at all, tables created on the fly, documents of any shape. Then you can gradually add schema definitions for some tables while leaving others untyped. Then you can turn on runtime validation. It mirrors TypeScript's own philosophy of incremental typing, and it's a fantastic approach for rapid prototyping and gradual hardening.
SpacetimeDB supports TypeScript and JavaScript modules, but our approach is more opinionated about types and schema. We believe types are critical for both correctness and performance, and with LLMs they just produce better code. For developers who want the freedom to prototype quickly without defining their data model upfront, Convex's gradual approach is arguably more flexible.
What we share (and why it matters)
Here's what I find most interesting about this whole situation. Despite the differences in implementation language, target audience, and developer experience, SpacetimeDB and Convex have converged on a remarkably similar API design. I think this convergence is not a coincidence. I think it reflects the fact that both teams, independently, arrived at what I believe is the correct set of foundational principles for building modern applications.
Both platforms provide:
ACID transactions. Both SpacetimeDB and Convex guarantee that your mutations are atomic and isolated. Your application state is always consistent. There is no "eventually consistent" hand-waving. No partial writes. No race conditions that only show up under load at 2am on a Saturday. Both platforms give you serializable isolation, the strongest guarantee available.
Real-time first. In both systems, subscribing to live data is not an afterthought bolted on with a WebSocket layer. It's the primary way clients interact with the backend. When data changes, subscribed clients are automatically notified. You don't manage connections or diff state or implement retry logic. It just works.
Type-safe APIs. Both systems generate typed client bindings from your backend definitions. When you change your schema or your function signatures, your client code knows about it at compile time, not at runtime when a user hits a bug.
Built-in authentication. Both platforms provide auth solutions so you don't have to cobble together a third-party provider from scratch (though both also support third-party providers if you prefer).
Your backend logic is unified with the database. This is the big one. Both Convex and SpacetimeDB reject the traditional architecture where your application server is a separate service with loosey goosey consistency semantics that talks to a separate database. Both systems offer transactional guarantees.
The concepts even map to each other fairly directly. Convex tables are SpacetimeDB tables. Convex mutations are SpacetimeDB reducers. Convex actions are SpacetimeDB procedures. Convex queries are similar to SpacetimeDB views. The terminology is different but the ideas are deeply similar. I think that although both teams were trying to solve different problems we were both drawn to the same conclusions about what a modern data platform should look like. These ideas have roots that go back decades to stored procedures and in our case the relational model (I've written before about Ted Codd and the relational model), and I think we're both building on that tradition.
I genuinely believe this is the direction all software development is headed. The days of hand-rolling REST APIs over Postgres, managing WebSocket infrastructure, and praying that your concurrent writes don't corrupt your data are numbered. Both SpacetimeDB and Convex represent what comes next, and I'm glad we're not alone in pushing in this direction.
Where SpacetimeDB shines
There are areas where we think SpacetimeDB has significant advantages, and I'd be doing you a disservice if I didn't mention them as well.
Performance. SpacetimeDB is fast. Really fast. Our architecture co-locates compute and storage in a single process, which eliminates the network hops that fundamentally limit throughput in distributed architectures, especially in cases with high database contention. Avoiding contention often means twisting your application into knots rather than just writing straightforward logic. In our benchmark, SpacetimeDB achieved over 100,000 transactions per second compared to Convex's roughly 100 on the same workload. That's not a marginal difference and could easily limit what you can build. Many applications where throughput and latency matter (games, simulations, collaborative tools with many concurrent users, accounting, metrics, etc.), are simply not possible to build with Convex or otherwise require separate services.
Language support. SpacetimeDB modules can be written in Rust, C#, TypeScript, or C++. Client SDKs are available for TypeScript, C#, Rust, and Unreal Engine. If you're building a game in Unity or Unreal, or if you want to write your backend in Rust for maximum performance, SpacetimeDB supports your workflow. And we have more languages on the way, like Swift and Kotlin, so you'll be able to write your whole app in a single language.
Convex is JavaScript/TypeScript only on the backend.
SQL, Postgres, and Incremental Query Evaluation. SpacetimeDB takes a different approach than Convex to our old friend SQL. While the Convex team rejects SQL wholesale, SpacetimeDB embraces it both for usability, compatibility, and performance.
SpacetimeDB lets you query your data with SQL right out of the box. With spacetime sql you can inspect or modify all of the data in your application as it changes in real-time. This is an incredibly powerful tool while building and debugging, but also for live operations and customer support. How do we know this? We operate SpacetimeDB in production for BitCraft.
SpacetimeDB also already supports the Postgres Wire Protocol, allowing you to hook up existing tools to SpacetimeDB. While SpacetimeDB doesn't support the full Postgres API, one of our stated goals is to become as compatible as possible so that existing tooling can work with SpacetimeDB.
Lastly, out of performance necessity, SpacetimeDB also takes a very different approach to implementing real-time subscriptions. In both Convex and SpacetimeDB, you can write regular procedural functions which "read" data from the database. In SpacetimeDB these are called "View Functions" and in Convex they are called "Queries". They are very convenient to use, it's just regular code and magically they update in real-time! There is a performance gotcha, however. Because they need to be updated in real-time, they must track a "read set" of anything that could affect their output. When anything in that set changes, the view function must be re-evaluated. This is fine for most web app situations, but for games like BitCraft it's a complete performance non-starter. This is because if many clients subscribe to data that other clients are modifying (e.g. players walking around in a world), then the view function for every client needs to be constantly re-evaluated. A straightforward naive approach can easily result in an N^3 explosion of work on the server. Every player movement request (of which there are N total for all players in a given time period) requires reevaluating the query function for every other player (N total players), where each query function loops through all other players (N total players).
SpacetimeDB's solution to this is incremental view maintenance and incremental query evaluation. Instead of requiring that you return data directly to clients in your view function, SpacetimeDB allows you to return a Query from view functions. We can then conceptually "take the derivative" of that query and incrementally maintain your view without needing to track the read set (we know what the query reads and can optimize it). This allows us to take the changes to your database and dispatch them directly to your client without needing to reevaluate the view function at all, we just incrementally evaluate your optimized query. The net result is that SpacetimeDB can handle situations where N clients are all making changes to the database state simultaneously.
These are real advantages and they matter for a lot of use cases. But they don't negate the areas where Convex is ahead today.
Looking forward
We intend to close the gaps I've outlined in this post. Better integrations, better LLM tooling, webhook support, and lower barriers to entry are all things we're actively working on. We also have a much bigger vision for where SpacetimeDB can go in the future as well as some very exciting buns in the oven, and I cannot wait to share them with you.
If you're building a real-time web application in TypeScript and you value a mature ecosystem of integrations, great LLM tooling, and a smooth getting-started experience, Convex is a great choice. If you're building something where raw performance matters, true real-time synchronization, where you need multi-language support, or where you want to write your backend in Rust, C++, or C#, SpacetimeDB is probably the better fit.
Either way, I think you're making a better choice than the old way of doing things. And I think more and more people are realizing it day by day.
If you want to chat about any of this, you can find me on Twitter or Bluesky, or come hang out in our Discord.