Astro DB ist deprecated: Was das für deine Datenbank bedeutet

Astro DB war die hauseigene Datenbank Integration von Astro und ist seit Astro 6.5 deprecated und wird nicht mehr gewartet. Die offizielle Empfehlung lautet, einen Datenbank Client wie Drizzle oder Kysely direkt im Astro Projekt einzusetzen statt auf das abgekündigte Paket @astrojs/db zu bauen.

Wichtig zu verstehen: Astro DB lief intern bereits auf libSQL, einem Open Source Fork von SQLite, und brachte einen eingebauten Drizzle ORM Client mit. Der Wechsel ist deshalb kein Bruch, sondern dieselbe Basis. Du sprichst SQLite und Drizzle jetzt direkt an, statt über das Paket @astrojs/db. Wer heute ein neues Astro Projekt mit Datenhaltung plant, nutzt direkt den Datenbank Client.

Für dich heißt das konkret: Schema und Queries definierst du mit Drizzle, die Daten liegen in einer lokalen SQLite Datei oder auf einem selbst gehosteten libSQL Server. Das gibt dir Type Safety, volle Kontrolle, On Premise Betrieb und keinen Vendor Lock in. Genau dieser Stack ist auch der Weg, den wir bei Never Code Alone in unseren Astro Projekten gehen.

Never Code Alone arbeitet täglich mit Astro und setzt in eigenen Projekten genau auf diesen Stack: SQLite und Drizzle direkt, ohne den Umweg über das Paket @astrojs/db. Wir kennen die Astro JS Grundlagen und die Astro Islands Architektur aus der Praxis und wissen, wo eine Datenhaltung in einem content getriebenen Framework Sinn ergibt und wo nicht.

Beim Aufbau einer sauberen Datenschicht hilft Type Safety von Anfang an: Wir verbinden Drizzle mit TypeScript im Strict Mode und Zod Schema Validierung, damit Eingaben und Datenbank Modelle zusammenpassen. Wir begleiten den Umstieg von Astro DB, richten lokale SQLite oder self hosted libSQL Setups ein und sichern die Qualität mit Vitest Tests. Mehr zu unserem Schwerpunkt findest du im Bereich Frontend Development.

Die Abkündigung steht so direkt in der offiziellen Astro Doku und im Changelog. Das eingebaute astro db CLI Kommando sowie die zugehörigen Befehle astro login, astro logout, astro link und astro init wurden entfernt. Das Paket @astrojs/db erhält keine weiteren Updates.

„The @astrojs/db package is now deprecated. We recommend using a database client directly instead.“

– Astro Docs, Juni 2026

Praktisch bedeutet das: Wer ein bestehendes Astro DB Projekt hat, sollte mittelfristig auf einen direkten Drizzle Aufbau wechseln. Wer neu startet, überspringt @astrojs/db komplett und installiert Drizzle plus einen SQLite Treiber selbst. Die Datenmodelle, die du eventuell schon in Drizzle Syntax geschrieben hast, kannst du in weiten Teilen weiterverwenden, weil Astro DB ohnehin auf Drizzle aufgesetzt hat.

Der Einstieg ist schlank. Du installierst Drizzle ORM, einen SQLite Treiber und das Drizzle Kit für Migrationen:

Danach legst du eine Drizzle Konfiguration an. Sie sagt Drizzle, welcher Dialekt genutzt wird, wo dein Schema liegt und wohin Migrationen geschrieben werden:

Das Schema definierst du typsicher in TypeScript. Drizzle generiert daraus Migrationen mit drizzle-kit generate und du fragst die Daten in Astro Pages, Endpoints oder Actions über den db Client ab. Die Datei app.db liegt im Projekt und damit vollständig On Premise.

Nicht jedes Projekt braucht denselben Aufbau. Mit Drizzle bleibt der Code fast gleich, während du die Datenhaltung an deine Anforderungen anpasst. Die folgende Übersicht zeigt vier typische Stufen, von der lokalen Datei bis zur skalierbaren PostgreSQL Datenbank. Alle Varianten lassen sich On Premise und DSGVO konform betreiben.

Astro ist ein content getriebenes Framework mit Server First Rendering. Eine schlanke, eingebettete Datenbank passt dazu besser als ein schwergewichtiger externer Dienst. Die wichtigsten Vorteile im Überblick:

• Type Safety: Drizzle leitet die Typen aus deinem Schema ab. In Kombination mit TypeScript im Strict Mode und Zod für Eingabevalidierung sind Datenfehler schon beim Kompilieren sichtbar.
• On Premise und DSGVO: Die SQLite Datei oder der libSQL Server liegen auf deinem eigenen Server in Deutschland. Keine Daten verlassen die Infrastruktur, kein US Cloud Zwang.
• Kein Vendor Lock in: libSQL und SQLite sind Open Source. Du bist an keinen gehosteten Anbieter gebunden und kannst jederzeit zu PostgreSQL wechseln.
• Performance: Eingebettete Datenbanken liefern extrem schnelle Lesezugriffe, ideal für die Islands Architektur und gute Core Web Vitals.

Der Umstieg ist überschaubar, weil die Basis gleich bleibt. In der Praxis hat sich dieser Ablauf bewährt:

1. Drizzle ORM, einen SQLite Treiber und drizzle-kit als Abhängigkeiten ergänzen.
2. Die bestehende Tabellendefinition aus der Astro DB Config in eine Drizzle Schema Datei überführen. Spaltentypen bleiben in weiten Teilen identisch.
3. Den Datenzugriff von astro:db Imports auf den eigenen Drizzle db Client umstellen.
4. Migrationen mit drizzle-kit generate erzeugen und gegen die Datenbank ausführen.
5. Vorhandene Daten exportieren und in die neue SQLite oder libSQL Datenbank importieren.

Wer libSQL als gehostete Variante nutzen will, kann die Datenbank auch self hosted betreiben und Drizzle per Verbindungs URL anbinden. Für größere Projekte ist der spätere Wechsel auf PostgreSQL ohne kompletten Code Umbau möglich, weil Drizzle denselben Query Builder über mehrere Dialekte anbietet. Bei einer geplanten Migration begleiten wir den Prozess Schritt für Schritt, damit keine Daten verloren gehen.

In unseren Astro Projekten setzen wir auf einen schlanken, typsicheren Datenstack: Drizzle für Schema und Queries, SQLite oder self hosted libSQL für die Speicherung, gehostet auf eigenen Servern in Deutschland. Wir beraten Teams dazu, welche Stufe für ihr Projekt passt, und richten den Aufbau gemeinsam ein.

Dabei achten wir auf ein sauberes Zusammenspiel mit dem restlichen Astro Stack: Astro JS als Framework, TypeScript im Strict Mode für Typsicherheit, Zod für Validierung und Vitest für Tests. Wer Wert auf Barrierefreiheit legt, kombiniert das mit den Accessible Astro Components. So entsteht ein Stack, der wartbar, DSGVO konform und langfristig tragfähig ist.

Die wichtigsten Fragen rund um das Astro DB Aus und den Umstieg auf einen direkten Datenbank Client kurz beantwortet.