SQLite Datenbank erstellen: neue .db-Datei anlegen

Eine SQLite-Datenbank ist einfach nur eine Datei

Wer von MySQL oder Postgres kommt, ist es gewohnt, mit CREATE DATABASE myapp; eine neue Datenbank anzulegen, die der Server dann irgendwo im Hintergrund verwaltet. Bei SQLite läuft das ganz anders. Es gibt keinen Server. Es gibt auch kein CREATE DATABASE-Statement. Eine SQLite-Datenbank ist schlicht eine ganz normale Datei auf der Festplatte – meist mit der Endung .db, .sqlite oder .sqlite3, aber die Endung ist reine Konvention.

Um eine SQLite-Datenbank zu erstellen, gibst du dem sqlite3-Tool einfach einen Dateinamen, der noch nicht existiert:

sqlite3 mydata.db

Das war's auch schon. Existiert mydata.db noch nicht, legt SQLite die Datei an. Ist sie schon da, wird sie geöffnet. Ein und derselbe Befehl deckt beide Fälle ab. Vom Konzept her ist das eher wie „ein Dokument öffnen" als wie „einen Datenbankserver hochfahren".

Die Datei taucht erst auf, wenn du etwas hineinschreibst

Genau hier stolpern viele. Führ den obigen Befehl aus, tipp .quit und schau in dein Verzeichnis. Von der Datei keine Spur.

SQLite ist faul. Solange nichts gespeichert werden muss, wird auch keine Datei auf der Festplatte angelegt. Sobald du aber eine Tabelle anlegst oder Daten committest, erscheint sie:

CREATE TABLE notes (
    id INTEGER PRIMARY KEY,
    body TEXT
);

Damit existiert mydata.db tatsächlich auf der Festplatte. Bis zu diesem ersten Schreibvorgang lebt die "Datenbank" nur im Speicher der Verbindung. Das sorgt manchmal für Verwirrung – kann aber auch praktisch sein, denn eine abgebrochene Sitzung hinterlässt so keinerlei Spuren.

SQLite Datenbank über die Kommandozeile anlegen

So sieht der komplette Ablauf in einer frischen Shell aus:

$ sqlite3 mydata.db
SQLite version 3.45.0
Enter ".help" for usage hints.
sqlite> CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
sqlite> .databases
main: /home/you/mydata.db r/w
sqlite> .quit

Ein paar praktische CLI-Befehle, solange du gerade drin bist:

• .databases — listet alle eingebundenen Datenbanken samt Dateipfaden auf.
• .tables — zeigt die Tabellen der aktuellen Datenbank.
• .schema — gibt die CREATE TABLE-Anweisungen für alles aus.
• .quit — beendet die Sitzung.

Falls du sqlite3 bereits ohne Datei gestartet hast (also ohne Argument aufgerufen), kannst du mit .open nachträglich eine Datei einbinden:

sqlite> .open mydata.db

Gleiche Regel: Ist die Datei nicht da, wird sie angelegt – sonst einfach geöffnet.

"If Not Exists" ist schon eingebaut

Eine typische Sorge von Leuten, die andere Datenbanken gewohnt sind: Was passiert, wenn die Datei schon existiert? Wird sie überschrieben? Nein. Eine bestehende Datei wird einfach geöffnet, nichts geht verloren. Das Pendant zu CREATE DATABASE IF NOT EXISTS ist hier schlicht: die Datei öffnen. SQLite kümmert sich mit demselben Befehl um beide Fälle.

Wenn du wirklich bei null anfangen willst, lösch die Datei vorher:

rm mydata.db
sqlite3 mydata.db

Überleg dir das aber gut. Es gibt kein Undo und kein Admin-Tool, mit dem du das Ganze wiederherstellen könntest.

SQLite-Datenbank in Python anlegen

In der Praxis wirst du die meiste Zeit nicht in der CLI unterwegs sein, sondern deine Datenbank direkt aus dem Anwendungscode heraus erstellen. Python bringt dafür das Modul sqlite3 von Haus aus mit – es ist Teil der Standardbibliothek und muss nicht extra installiert werden:

-- Äquivalenter Python-Code:
-- import sqlite3
-- conn = sqlite3.connect("mydata.db")
-- conn.execute("CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT)")
-- conn.commit()
-- conn.close()

CREATE TABLE notes (
    id INTEGER PRIMARY KEY,
    body TEXT
);

sqlite3.connect("mydata.db") verhält sich genauso wie die CLI: Ist die Datei nicht da, wird sie angelegt — ist sie da, wird sie geöffnet. Alle anderen Sprach-Bindings (Nodes better-sqlite3, Gos database/sql-Treiber, Rusts rusqlite usw.) funktionieren nach demselben Prinzip, denn unter der Haube steckt überall dieselbe C-Bibliothek.

Eine Python-spezifische Abkürzung: Wenn du ":memory:" als Pfad übergibst, bekommst du eine SQLite In-Memory-Datenbank, die komplett im RAM lebt und beim Schließen der Verbindung wieder verschwindet. Dazu mehr auf der nächsten Seite.

Wo soll die .db-Datei liegen?

Weil die Datenbank schlicht eine Datei ist, stellt sich die Frage „Wohin damit?" tatsächlich. Ein paar Faustregeln:

• Bei einer Anwendung: irgendwo im Datenverzeichnis des Nutzers oder im Arbeitsverzeichnis deiner App. Leg sie nicht direkt neben die ausführbare Datei — auf vielen Systemen ist dieser Pfad nicht beschreibbar.
• Bei einem Projekt: im Repo-Root oder in einem data/-Ordner. Wenn die Datei lokalen Zustand enthält, gehört sie in die .gitignore — eine binäre Datenbank ins Git einzuchecken geht selten gut aus.
• Bei Tests: nimm :memory: oder eine temporäre Datei. Schnell und räumt sich von selbst auf.

Auch die Berechtigungen sind wichtig. Der Benutzer, unter dem der Prozess läuft, braucht Lese- und Schreibrechte auf die Datei und auf den übergeordneten Ordner (SQLite legt während Schreibvorgängen Lock-Dateien daneben an).

Kurzer Funktionstest

Damit du siehst, dass die ganze Kette wirklich funktioniert:

CREATE TABLE greetings (
    id INTEGER PRIMARY KEY,
    message TEXT NOT NULL
);

INSERT INTO greetings (message) VALUES ('hallo'), ('welt');

SELECT * FROM greetings;

Du solltest zwei Zeilen zurückbekommen. Wenn das klappt, existiert deine Datenbankdatei, das Schema steckt drin und du kannst die Daten abfragen. Das war's auch schon mit dem Thema „SQLite-Datenbank erstellen" – kein Server, keine Benutzer, keine Berechtigungstabelle. Einfach nur eine Datei.

Als Nächstes: In-Memory-Datenbanken

Derselbe Aufruf sqlite3.connect(...), der eine Datei anlegt, erzeugt mit dem passenden Argument auch eine Datenbank, die niemals auf die Platte geschrieben wird. In-Memory-Datenbanken sind der schnellste Weg, um Tests laufen zu lassen, ein Schema auszuprobieren oder kurzlebige Daten zwischenzuspeichern. Genau darum geht's im nächsten Abschnitt.