Convex, reviewed: a reactive backend that thinks in TypeScript

Convex is a backend-as-a-service that takes a different angle from the Supabase/Firebase mainstream. Instead of giving you a Postgres database with auth and edge functions stapled on, Convex ships a single integrated runtime where every query is reactive, every function is typed end-to-end, and the database, scheduler, file storage, and vector search all share the same TypeScript surface. For solo founders building real-time or AI-heavy products, that integration is either the killer feature or the wrong abstraction — this review walks through which.

What Convex actually is

Convex calls itself the “open-source reactive database for app developers.” In practice it’s a hosted backend platform that bundles four things behind one TypeScript SDK: a document database (with relational queries), a serverless function runtime, scheduled jobs, and primitives for file storage and vector search. The pitch is that you write your backend as a folder of TypeScript files in your existing repo, push them with a single CLI command, and the client SDK gives you live-updating data without writing a websocket layer.

That positioning makes Convex a direct competitor to Firebase and a sideways competitor to Supabase. The core differences as documented:

• Reactive by default. Every query subscribes to its inputs. When the underlying data changes, every connected client re-runs the query and gets the new result automatically. No manual cache invalidation, no GraphQL subscriptions, no polling.
• TypeScript end-to-end. Schema, validators, server functions, and client types are all generated from one source. The client knows the shape of every query return value at compile time.
• One runtime. Database, functions, cron jobs, file storage, and vector search are not separate services with separate billing meters. They’re one platform with one bill.
• Open source. The Convex backend is source-available under a fair-use license; you can self-host (with operational caveats) if you ever need to.

Convex was founded in 2021 by ex-Dropbox engineers and is one of the few BaaS platforms not chasing Postgres-shaped workloads. If you want SQL, this is the wrong tool. If you want a real-time-by-default app with no plumbing, this is exactly the right tool. We dig into the broader Postgres-vs-document trade-off in our serverless Postgres explainer.

The reactive model: queries, mutations, actions

The mental shift Convex asks for is the reactive model. Where REST has endpoints and GraphQL has resolvers, Convex has three function types, each with different rules:

Queries

Queries are pure, deterministic reads of the database. They run inside Convex’s transaction layer and are cached and reactive — the runtime tracks every document a query touches, and when any of those documents change, every subscribed client re-runs the query and pushes the new result down the wire. Queries can’t call external services, can’t mutate data, and can’t use random numbers or timestamps directly. The discipline is what makes the reactivity work.

Mutations

Mutations write to the database, also inside a transaction. They’re serializable and atomic — if a mutation throws, every change rolls back. Mutations can read the database freely, do business logic, schedule future work, but cannot call external HTTP endpoints. That last constraint is intentional: external calls are non-deterministic and can’t be safely retried.

Actions

Actions are the escape hatch. They run outside the transactional database, can call any external API (Stripe, OpenAI, SendGrid), and use the full Node.js runtime. Actions can’t directly read or write the database — they call mutations and queries to do that. The pattern is: a mutation enqueues an action, the action calls an LLM or sends an email, then the action calls another mutation to write the result back.

Coming from REST, this three-tier split feels like overhead until you realize it’s what makes the reactivity tractable. The runtime can confidently re-run queries because they’re pure; it can confidently retry mutations because they’re transactional; it can confidently throw actions at flaky external APIs because they’re isolated. For an AI app where you’re streaming tokens from Claude into a chat UI, the action-mutation-query loop is a natural fit — we walk through this exact pattern in our AI chatbot SaaS guide.

TypeScript-first: schema in TS, types end-to-end

Most BaaS platforms treat types as a developer convenience layer bolted on top of the database. Convex inverts that: the schema lives in convex/schema.ts as a TypeScript file using Convex’s validator DSL, the CLI generates types into convex/_generated/, and every server function imports those types. The client SDK consumes the same generated module, so when you call useQuery(api.tasks.list) in React, the return type is inferred — no codegen step, no manual type annotation, no GraphQL fragment.

The practical implications, per the docs:

• Schema changes that break a query surface as TypeScript errors in the client at compile time, not runtime errors in production.
• Refactoring a field rename across 40 components is a single find-and-replace because the types track usage.
• The validator runs on every mutation argument at runtime, so the type system is also the input-validation layer — no separate Zod step.

This is the strongest selling point for solo TypeScript founders. The class of bugs that come from drift between “what the database actually contains” and “what the frontend thinks the database contains” mostly disappears. The trade-off is lock-in: you’re writing in Convex’s flavor of TypeScript, not in a portable framework.

Pricing tiers

Convex publishes three plans on convex.dev/pricing:

The Free tier is unusually permissive for a backend platform — 1M function calls covers a meaningful amount of traffic for an early product. The Pro tier’s $25 base is in line with Supabase Pro and well below Firebase Blaze at comparable usage, but Convex meters function calls (every query, mutation, and action invocation) so reactive-heavy apps with chatty subscriptions can rack up call counts faster than founders expect. Always model the meter against your actual subscription pattern.

When Convex fits

Three product shapes where Convex is genuinely the best tool:

• Real-time collaborative apps. Multiplayer cursors, shared documents, live dashboards. The reactive query model removes 80% of the websocket plumbing you’d otherwise write.
• AI chat with streaming. An LLM action streams tokens, mutations append messages, and the client sees the conversation update live without any subscription wiring. The action-mutation-query split maps cleanly onto how LLM apps actually work.
• Internal tools and dashboards. Anywhere you’d otherwise reach for Firebase Realtime Database, Convex gives you the same live-updating UX with stronger types and a sane query model.

If you’re building any of these and you’re already in TypeScript, Convex is a top-three choice. The DX of seeing your client update without writing a single subscription handler is hard to give back once you’ve experienced it.

When Convex doesn’t fit

Three scenarios where Convex is the wrong tool:

• You need raw SQL or complex Postgres features. Convex is a document database with relational queries, not a SQL database. No window functions, no recursive CTEs, no PostGIS. If your product needs aggregate reporting or a data analyst writing ad-hoc queries, you want Postgres — see our Supabase vs Neon comparison.
• You have an existing data warehouse or analytics pipeline. Convex offers streaming exports, but the gravity of your data still lives in Convex’s storage. If you already run BigQuery, Snowflake, or a Postgres-based analytics stack, the integration story is more friction than a Postgres BaaS.
• You want maximum portability. Convex’s reactive model is its lock-in. The schema, the function shape, and the client-server contract are Convex-specific. Migrating off Convex means rewriting the backend, not just dumping a SQL schema.

For SQL-shaped workloads, Supabase or Neon plus a typed query layer (Drizzle, Prisma, Kysely) is the stronger pick. We round up the SQL-side options in best Supabase alternatives.

Convex vs Supabase vs Firebase

Convex vs Supabase

Supabase is Postgres-as-a-service plus auth, storage, and edge functions. Convex is a reactive document database plus functions, storage, and vector search. They look similar on a feature checklist but solve different problems. Supabase wins if you want SQL, want to integrate with the existing Postgres ecosystem, or care about data portability. Convex wins if you want real-time-by-default and can live without SQL. Pricing is roughly comparable at the Pro tier; the lock-in curve is steeper with Convex. Our Supabase vs Firebase comparison covers a lot of the relational-vs-document framing that applies here too.

Convex vs Firebase

Firebase (Firestore + Cloud Functions) is the closest historical analogue: a document database with real-time subscriptions and a serverless function layer. Convex’s pitch against Firebase is stronger types, better local DX, a more coherent transaction model, and an integrated TypeScript SDK that doesn’t require generating clients. Firebase’s pitch against Convex is Google scale, a deep mobile SDK story, and a much larger third-party ecosystem. For a TypeScript-first solo founder building a web app, Convex is the more modern pick. For an Android-first mobile app, Firebase still wins.

Convex vs the Hono/Drizzle stack

An increasingly popular alternative for solo founders is gluing your own backend together: Hono or tRPC for the API, Drizzle or Prisma for the ORM, Postgres on Neon or Supabase, and your choice of auth. This stack gives you maximum flexibility and SQL semantics, at the cost of writing every piece of plumbing yourself. Convex trades the flexibility for an integrated, opinionated runtime. The right pick depends on whether you value control more than convenience — we map the broader trade-off in our best SaaS tools for developers roundup.

The verdict

Convex is the cleanest reactive backend on the market for TypeScript-first solo founders, and the Free tier is generous enough to take a product to its first paying customers without paying anything. The reactive model and end-to-end types are genuinely productive once you internalize them, and the integrated runtime removes a real category of glue code.

The honest caveats are the document model (no SQL), the lock-in curve (the reactive contract is Convex-specific), and the function-call meter (chatty real-time apps can burn through call counts faster than you’d expect). If your product is real-time, AI-heavy, or collaborative, Convex deserves a serious look. If your product is reporting-heavy or needs Postgres semantics, stay on the SQL side of the BaaS market.

Related reading

• Best Supabase alternatives in 2026
• Supabase vs Firebase — relational vs document trade-offs
• Supabase vs Neon — two takes on serverless Postgres
• What is serverless Postgres?
• Best SaaS tools for developers
• How to build an AI chatbot SaaS with Claude