Convex vs Layerbase: a reactive backend, or a database you own?

Convex is one of the more genuinely interesting things to happen to app backends in a while, so let me start by being fair to it: if you are building a new app and you want your database, your server logic, and your realtime updates to be one integrated thing, Convex is very good at that. This is not a hit piece.

But "Convex vs Layerbase" is a slightly odd matchup, because the two tools answer different questions. Convex answers "how do I build a reactive backend without wiring up a database, an API layer, and a websocket server myself?" Layerbase answers "how do I run a real, standard database that I own and can connect to with the drivers I already use?" You can build the same app on either. The decision is really about how much of your stack you want a single vendor to define.

Here is the honest side by side.

What Convex actually is

Convex is a reactive backend platform. You write your backend as TypeScript functions: queries (read), mutations (transactional write), and actions (side effects, calling other APIs). Those functions run against a document-relational database with a schema you define in TypeScript. The headline feature, and it is a real one, is reactivity: a query subscribed from your client re-runs and pushes new results automatically whenever the underlying data changes. You do not write websocket code, you do not poll, you do not hand-roll cache invalidation. It just updates.

On top of that, Convex bundles the things a backend usually needs: file storage, scheduled functions and cron, full-text and vector search, HTTP endpoints, and auth integrations. It is an opinionated, batteries-included package, and the batteries are good.

Two things people often do not realize, and both are to Convex's credit:

• Convex is open source. The backend is published under the FSL (which converts to Apache 2.0 two years after each release), and you can self-host it in Docker, backed by SQLite or Postgres, with the dashboard and CLI included.
• Your data is not trapped. npx convex export and npx convex import move full snapshots in and out.

So the lazy "proprietary backend, you can never leave" criticism is not accurate anymore. Give them credit for that, it matters for what follows.

What Layerbase is

Layerbase Cloud is managed hosting for standard databases. You pick an engine (Postgres, MySQL, MongoDB, Redis, ClickHouse, and about twenty others), you get a real instance speaking that engine's actual wire protocol, and you connect to it with the same drivers, ORMs, and tools you already use. There is no Layerbase SDK to adopt and no Layerbase-specific way to write a query. A Postgres on Layerbase is just Postgres.

The free dev tier needs no credit card, databases scale to zero when idle and wake on connect, and paid capability (branching, scheduled backups, keep-warm, mTLS, region pinning) is flat add-ons rather than per-seat charges.

The tradeoff runs the opposite direction from Convex: Layerbase gives you a database, not a backend. It does not ship reactivity, a function runtime, or an integrated auth system. You bring your own API layer and your own framework. In exchange, nothing about your application code is coupled to Layerbase.

At a glance

The real question: a backend, or a database?

This is the whole decision, so it is worth saying plainly.

Convex is a bet that letting one platform own your data model, your server functions, and your realtime layer is worth writing your app in that platform's shape. When the bet pays off, and for a lot of greenfield apps it does, you move very fast and you delete a lot of glue code.

Layerbase is the opposite bet: keep the database a boring, standard, swappable component, and keep your application logic yours. You write more of the plumbing, and in return you can move the database to any host that speaks the same protocol, run the same engine locally, and never rewrite a query because you changed vendors.

Neither bet is wrong. They are different appetites for coupling.

Reactivity is Convex's real edge

Let me not undersell this. Realtime-by-default is the thing Convex does that a plain managed database does not, and it is genuinely hard to reproduce. If your app is collaborative, live-updating, multiplayer, or dashboard-heavy, and reactivity is the core of the experience, Convex hands you that on day one. On Layerbase, or any standard Postgres host, you would build it yourself: LISTEN/NOTIFY or logical replication feeding a websocket layer you operate. That is real work.

If reactivity is your product, that is a strong reason to choose Convex, and I am not going to pretend a connection string competes with it.

What you trade for it is generality. Convex reactivity works because Convex controls the query engine, the function runtime, and the client. That is exactly the coupling described above: worth it for some apps, overkill for a CRUD app with a REST API and the occasional refetch.

Lock-in, honestly

The fair version of the lock-in argument is not about your data. As covered, Convex exports cleanly and self-hosts. The lock-in is your code.

Your queries and mutations are written against Convex's API. Your schema is defined in Convex's TypeScript format. Your reactivity assumes Convex's client. If you decide in two years to move off Convex, exporting the data is the easy part. Rewriting every backend function that was expressed as a Convex query or mutation is the real cost, and there is no automated path for it, because there is no standard those functions conform to.

With Layerbase there is nothing to rewrite, because there was never a Layerbase-specific layer. You were writing SQL (or Redis commands, or Mongo queries) against a standard engine the whole time. Moving hosts is a dump and restore, or logical replication for zero downtime.

So: Convex's data is portable, Convex's programming model is not. Layerbase's whole surface is the standard, so both are. Which of those you care about depends on how likely you think you are to leave, and how much code you will have written by then.

Pricing: per developer vs per database

Convex's paid plan is Professional at $25 per developer per month, on top of a free Starter tier that goes pay-as-you-go past its limits. Per-developer pricing is normal for integrated platforms, but note the shape: a three-person team is $75 a month before a single byte of usage overage, because you pay for seats, not databases.

Layerbase does not charge per seat. The engine is free on the dev tier, and paid capability is flat add-ons on the database itself. For a solo developer the two can both be cheap. For a small team, per-seat pricing adds up in a way per-database pricing does not.

As always with usage-based platforms, the number to watch on Convex is the overage past the plan's included storage, I/O, egress, and function calls. It is fair pricing and clearly documented. It is just variable, and variable bills are the thing people most often want to escape.

Engines and portability

Convex is one database: its own document-relational store. That is a feature (one model to learn) and a limit (if your workload wants columnar analytics, a vector index at scale, a ledger, or plain relational Postgres with the full extension ecosystem, you are either fitting it into Convex's model or running a second system alongside it).

Layerbase is deliberately multi-engine. Analytics on ClickHouse or DuckDB, vectors on Qdrant or Weaviate, full-text on Meilisearch, relational on Postgres or MySQL, all from one dashboard, all standard. If your stack is one app with one data model, that breadth is irrelevant. If it is several services with different data shapes, it matters a lot.

You can also run the exact same engines locally with SpinDB and deploy the same thing to Layerbase Cloud, so local and production are the identical binary. That is a nice-to-have, not the headline.

Which one to pick

• Building a greenfield, realtime-first app (collaborative, multiplayer, live dashboards) and happy to write it in Convex's shape: Convex. The reactivity alone earns it.
• You want an integrated backend and to delete glue code, and you do not expect to leave: Convex. That is what it is for, and it is good at it.
• You want a real, standard database you connect to with your existing drivers and ORM, with no programming model to adopt: Layerbase.
• You are a small team and per-seat pricing bothers you, or you want predictable, flat, per-database costs: Layerbase.
• Your stack spans multiple data models (relational plus analytics plus vectors plus cache) and you want them standard and in one place: Layerbase.
• You are hedging a strategic dependency and want to be able to change vendors in a weekend without a rewrite: Layerbase, because there is nothing vendor-specific to rewrite.

The honest gap, stated plainly: if you want reactivity out of the box on a database you fully own, neither Convex (own the model, not the code) nor a plain managed Postgres (own everything, build the realtime layer yourself) is a perfect fit today. Most teams do not need reactivity badly enough to organize their whole backend around it, which is why standard databases are still the default. If you do need it, Convex is the shortest path.

Try it

If a standard database you own beats an integrated backend for what you are building, create a free Postgres on Layerbase Cloud. No card, no SDK to adopt, no per-seat bill, and the same psql URL and drivers you already use. Pick a different engine from the same create flow if Postgres is not your shape.

And if Convex is genuinely the right fit for your app, use Convex. Picking the tool that matches the shape of what you are building beats picking the one a comparison post is nominally selling.