Skip to content
LayerbaseLayerbase

Should you use Lakebed for database hosting?

7 min readLakebedLayerbase CLIDatabasesDeveloper Tools

Lakebed has been getting attention lately, partly because of the idea and partly because of who is building it. If you have seen it and wondered whether it is somewhere you would host a database, this is an honest answer. We build database tooling (the Layerbase CLI and Layerbase Cloud), so the bias is on the table. We are going to be fair anyway, because the honest read on Lakebed is more interesting than a takedown.

Short version: Lakebed is a neat experiment, but it is not a database host, and it does not present itself as one. The database inside it is a feature of an app runtime, not a product you provision and connect to. If what you actually want is a database, the Layerbase CLI already gives you more convenience than Lakebed does today, plus the things Lakebed does not have: real engines, connection strings, branching, and a Vercel integration.

Contents

What Lakebed actually is

Lakebed describes itself as an agent-native CLI and runtime for building small full-stack TypeScript apps it calls "capsules." A capsule bundles a server, a client UI, an auth layer, a built-in datastore, logs, and a deploy URL, and the whole thing is shaped so an AI coding agent can write the app, run it, inspect it, and ship it without a human babysitting each step. The homepage tagline is "Let the agents build. Get out of their way."

It is currently labeled alpha, and it reads like an early, opinionated project: the published package is in the 0.0.x range, there is no pricing page, and the docs are candid about v0 limits (no file storage yet, no arbitrary npm imports inside a capsule, an in-memory database during local dev that resets on restart). None of that is a criticism. It is what an early, experimental product looks like, and Lakebed does not pretend otherwise.

The genuinely good part is the agent ergonomics. The deploy flow is frictionless (ship an anonymous build, then claim it to get a subdomain and a real server environment), and the documentation is some of the cleanest agent-facing docs around. That last point impressed us enough that we wrote up our own notes on the pattern. Lakebed is a real, thoughtful take on "what does a cloud look like when agents are the primary users."

Credit where it is due: Theo Browne

Lakebed comes from Theo Browne (t3.gg) and his company Ping Labs. He has referred to it publicly as "my cloud," and it fits the rest of his work.

Theo has a real track record. He spent about five years as an engineer at Twitch before going full time on his own company, which is Y Combinator backed. He is one of the more widely followed developer voices on YouTube, reaching hundreds of thousands of developers, and he is best known for the T3 Stack and create-t3-app, the opinionated TypeScript starter that a large slice of the ecosystem has used to bootstrap apps. His company also ships products people actually use, including UploadThing and T3 Chat. He is opinionated, and people in web dev tend to take his bets seriously, because he ships.

So when we say Lakebed is an experiment, that is not a knock. Theo builds experiments that sometimes turn into the thing everyone uses. It is worth watching. It is just not, today, a database host.

The database is a feature, not the product

This is the crux, and it is why "should I host my database on Lakebed" is the wrong question.

In Lakebed, the database is exposed inside a capsule as an abstraction called ctx.db. You define tables in code, and every row gets an id, createdAt, and updatedAt; you query with where, orderBy, limit, and the like. That is a perfectly reasonable app-data layer. But notice what is missing:

  • The engine is never named. The docs do not say Postgres, SQLite, libSQL, MySQL, or anything else. The database is an implementation detail of the runtime.
  • There is no connection string and no external access. You cannot point psql, a BI tool, or another service at it. The data only exists inside the capsule that owns it.
  • In local development it is in-memory and resets when you restart the dev server.

That is a deliberate design for agent-built apps, where the database should be invisible and self-managing. It is also the clearest possible signal that databases are not the priority here. They are tacked on for completeness so that a capsule can store state, not built out as something you would run a real workload on and depend on directly.

What that means if you want a database

If your actual goal is "I need a database for my project," Lakebed does not give you the things that goal implies:

  • No choice of engine. One opaque store, not Postgres or MySQL or Redis or twenty others.
  • No branching. No instant copy of a database for a preview or a test.
  • No provisioning surface. There is no "create a database, here is your connection string" flow, because the database is not a standalone object. There is no external API to script database creation against.
  • No platform integration. No Vercel integration, because Lakebed is itself the host. It is a target, not something that plugs into where you already deploy.
  • No external clients. Your existing app, ORM, dashboard, or analytics tool cannot connect to it.

Again, this is not Lakebed failing at being a database host. It is Lakebed being a different thing.

The Layerbase CLI already does the convenient part

The interesting comparison is not Lakebed versus a big managed-database dashboard. It is Lakebed versus the Layerbase CLI, because the CLI is the scriptable, get-out-of-your-way surface that an agent (or a developer in a hurry) would actually drive, and it is built around real databases.

The CLI runs anywhere Node runs, on macOS, Windows, and Linux. Under it, SpinDB runs more than 20 database engines locally with no Docker. (What is SpinDB?)

bash
npm i -g layerbase   # the Layerbase CLI (cloud + local bridge)
npm i -g spindb      # the open-source engine runner underneath

Stand up a real Postgres locally in one command:

bash
spindb create my-app -e postgresql --start --connect
sql
CREATE TABLE notes (
  id SERIAL PRIMARY KEY,
  body TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

INSERT INTO notes (body) VALUES ('first note');
SELECT * FROM notes;

That is a genuine Postgres with a connection string you can hand to any tool. Swap -e postgresql for mysql, valkey, mongodb, libsql, or any of the others. The Layerbase CLI then bridges that local workflow to the cloud: list your managed databases, connect to them, and clone a cloud database down to a local SpinDB instance with a single command.

So the conveniences Lakebed is admired for, one command to a working thing, an agent-friendly CLI, have an answer here already, and the answer comes with the parts Lakebed lacks for database work:

  • Real, named engines (more than 20), with standard connection strings.
  • Branching, an instant copy of a database for previews and tests.
  • A Vercel integration that maps your project branches to managed databases automatically.
  • A web query console, scheduled backups, scale-to-zero, and dedicated bare-metal on the Custom plan.

In other words, today the Layerbase CLI gives you at least as much convenience as Lakebed, and it gives you actual databases on top.

It may get there

To be fair to the idea: a self-managing database that an agent never has to think about is a reasonable direction, and Lakebed is early. If it grows a real database surface (a named engine, a connection string, external access, branching), the calculus could change, and given Theo's history it is worth keeping an eye on. We would happily revise this post if that happens.

But that is a future-tense argument. Right now, Lakebed treats the database as plumbing for an app runtime, which is the right call for what it is trying to be and the wrong fit if you came looking for a database.

Which one to reach for

  • You want an agent to build and deploy a small full-stack TypeScript app, and the data layer should be invisible: Lakebed is a genuinely interesting place to experiment, and the agent ergonomics are real. Go play with it.
  • You want a database (any engine, a connection string, branching, something your existing stack and tools can connect to, something that integrates with Vercel): reach for the Layerbase CLI and Layerbase Cloud. That is the job they are built for.

The two are not really competitors. They just get filed under the same search sometimes. If the word you typed was "database," this is the side of that line you want.

Create a free Postgres on Layerbase Cloud, or install the CLI with npm i -g layerbase and run layerbase to connect your local and cloud databases in one place.

Something not working?