Astro 7 Is Deprecating Astro DB. If You Built on It, You Have a Migration Window — Here's the Honest Read.
The Astro 7.0 beta is out, and buried in the changelog is the line that matters if you ever took Astro up on its database offer: the astro db CLI commands are gone, and @astrojs/db is deprecated. Astro DB, the framework's first-party, managed SQL layer, is being walked to the exit. This blog runs on Astro, so this is a first-person read, not a press-release rewrite.
If you never touched Astro DB, this is a non-event and you can skim. If you did (if you've got content, app data, or a side project sitting in it), the framework just handed you a migration window, and the smart move is to use it deliberately rather than wait for the package to actually break.
What's actually changing in v7
Three things, in order of how much they'll touch you.
The big one: the astro db commands are removed from the CLI in v7, and @astrojs/db is deprecated: the Astro team said plainly they no longer have the bandwidth to maintain it and recommend using a database client like Drizzle or Kysely directly instead. The deprecation actually landed back in v6.5; v7 is where the CLI tooling comes out. A few adjacent auth/init commands (astro login, astro logout, astro link, astro init) are also gone. Deprecated doesn't mean it vanishes the instant you run npm install astro@7, but it does mean no more investment, no future fixes, and a clock that's now running. Building anything new on it would be choosing a dead-end on purpose.
The second one, which is good news: advanced routing is now the default. It was experimental behind a flag in v6.3, and in v7 you don't need the flag anymore. If you'd been waiting for it to stabilize before relying on it, the wait's over.
The third bucket is the usual polish: the custom logger graduates out of experimental, and there's a new subset field on FontData for sites juggling multiple font subsets. Nice to have, not why you're reading this.
For context: Astro 6, back in March, rebuilt the dev server on Vite's Environment API and added Content Security Policy support. So v7 is the second straight release where the framework is shedding the parts that were more burden than benefit and standardizing what's left. The DB deprecation fits that pattern.
Why first-party databases in frameworks keep dying
This isn't really an Astro story. It's a pattern, and the pattern is worth more than the specific news.
Frameworks keep shipping a built-in database, and they keep deprecating it. The reason is structural. A web framework's job is rendering, routing, and the build. A database is a different business entirely: durability, backups, scaling, migrations, support when someone's production data is on the line. Maintaining a managed data layer is a heavy, expensive, never-ending commitment that has almost nothing to do with the framework's actual core. When budgets tighten or priorities sharpen, the bolt-on database is the first thing to get cut, because it was never load-bearing for the team that maintained it, only for the developers who trusted it.
The lesson for a solo operator is the one I keep relearning: don't marry the convenience database your framework hands you. The convenience is real, the lock-in is invisible until the deprecation note lands, and then you're doing a data migration on someone else's schedule instead of your own.
Where to move
The good news is Astro DB was built on libSQL, so you're not starting from a strange place. Two paths cover almost everyone.
If you want to stay close to what you had, move to Turso or self-hosted libSQL directly. It's the same engine Astro DB sat on top of, you drop the framework wrapper, and you talk to the database with a normal client. This is the lowest-friction path and the one I'd default to for a content site.
If you're building something with real relational complexity or you want maximum portability, go to Postgres with Drizzle (or Prisma if that's your taste). It's more setup, but you end up on the most boring, most portable, least-likely-to-be-deprecated stack in existence, which is exactly what you want underneath data you care about. Boring is a feature when it's holding your production records.
Either way, the migration itself is mechanical: stand up the new database, port the schema, move the rows, swap your data-access calls, test, cut over. On a typical solo project that's an afternoon, not a death march, if you do it while v6 still works and @astrojs/db still functions, instead of waiting until something forces your hand.
What I'd actually do
If you're on Astro DB: start the migration now, on v6, before you touch the v7 upgrade. Get your data onto Turso or Postgres while the old package is still working and you can run both side by side. Decouple the database move from the framework bump so you're never debugging two things at once. Then upgrade Astro on its own.
If you're not on Astro DB but you're on Astro: don't rush to v7 yet. It's still beta. Let it reach stable, watch the first couple of patch releases for the usual rough edges, and upgrade when there's nothing forcing you not to. The advanced-routing default is a nice pull, but not worth riding a beta in production for a solo site.
And the durable takeaway, the one that outlives this particular release: whatever framework you're on, keep your database one decision removed from it. The framework should render your data, not own it. The day it deprecates the convenience layer (and it always eventually does), you want that to be an afternoon of work, not a fire.
Author
Lukas
@lukcombinator