In-Memory, H2, SQLite: Was du wirklich wissen musst

Wenn du mit Java anfängst, stolperst du früher oder später über Begriffe wie H2, In-Memory-Datenbank oder SQLite. Auf den ersten Blick klingt das alles ähnlich. Irgendwie geht es um Datenbanken, oft um kleine Projekte, lokale Tests oder einfache Anwendungen. In der Praxis steckt dahinter aber nicht immer dasselbe. Genau das sorgt am Anfang schnell für Verwirrung.

Der wichtigste Punkt direkt zu Beginn: H2 und SQLite sind konkrete Datenbanksysteme. In-Memory ist dagegen erst einmal nur eine Eigenschaft.

Und ja, es gibt in diesem Bereich noch mehr. Im Java-Umfeld begegnen dir zum Beispiel auch HSQLDB oder Apache Derby. Beide sind ebenfalls leichte relationale Datenbanken, die oft für lokale Entwicklung, Tests oder kleine Anwendungen genutzt werden. Für den Einstieg tauchen in der Praxis aber meistens H2 und SQLite zuerst auf, weil sich an ihnen die grundlegenden Unterschiede besonders gut erklären lassen. Eine In-Memory-Datenbank speichert ihre Daten im Arbeitsspeicher statt dauerhaft auf der Festplatte. Das bedeutet: H2 kann in einem In-Memory-Modus laufen, SQLite dagegen ist in erster Linie eine dateibasierte Datenbank. Wenn du diese Unterscheidung einmal sauber verstanden hast, wird vieles deutlich einfacher.

H2 und In-Memory sind nicht dasselbe

H2 ist eine leichtgewichtige relationale Datenbank, die im Java-Umfeld sehr bekannt ist. Sie wird oft in kleinen Projekten, bei Tests oder in Beispielanwendungen eingesetzt. Ein großer Vorteil ist, dass sie sich unkompliziert in ein Maven-Projekt einbinden lässt und sofort startklar ist. Gerade wenn du mit IntelliJ arbeitest und schnell etwas ausprobieren willst, ist H2 ziemlich angenehm.

Ein typischer Maven-Eintrag sieht zum Beispiel so aus:

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>

Spannend wird H2 durch die verschiedenen Betriebsarten. Du kannst H2 als In-Memory-Datenbank starten. Dann liegen die Daten nur im RAM und sind weg, sobald deine Anwendung beendet wird. Genau das ist praktisch für Tests oder kurze Demos, weil du jedes Mal mit einem sauberen Zustand startest.

Eine einfache JDBC-URL dafür sieht so aus:

String url = "jdbc:h2:mem:testdb";

H2 kann aber auch dateibasiert laufen. Dann werden die Daten auf der Festplatte gespeichert und stehen beim nächsten Start wieder zur Verfügung. Das ist wichtig, weil H2 also nicht automatisch nur eine In-Memory-Datenbank ist. H2 ist das Produkt. In-Memory ist nur eine mögliche Betriebsart.

Für dich im Alltag heißt das: Wenn du schnell testen willst, ist H2 im In-Memory-Modus oft ideal.

An der Stelle lohnt sich noch eine saubere Einordnung: H2 gehört zusammen mit HSQLDB und Apache Derby in die Ecke der kleinen, eingebetteten relationalen Datenbanken, die sich direkt in Anwendungen oder Testumgebungen nutzen lassen. SQLite passt ebenfalls in die Welt der leichten Datenbanken, ist technisch aber stärker über die Datenbankdatei und weniger über das klassische Java-Ökosystem geprägt. Wenn du lokal etwas entwickeln willst, das zwischen zwei Starts seinen Zustand behalten soll, kannst du H2 auch mit Datei verwenden. Genau deshalb taucht H2 in vielen Java-Projekten auf, die mit JavaEE, Jakarta EE oder Spring arbeiten. Sie ist leicht integrierbar, schnell verfügbar und für Grundlagen gut verständlich.

Was SQLite anders macht

SQLite ist ebenfalls eine relationale Datenbank, verfolgt aber einen etwas anderen Ansatz. Sie läuft nicht als klassischer Datenbankserver, sondern speichert die komplette Datenbank in einer Datei. Genau das macht SQLite so interessant für kleine Tools, Desktop-Anwendungen, mobile Apps oder lokale Programme mit überschaubarem Datenvolumen.

Eine SQLite-Datenbank ist oft einfach nur eine Datei wie app.db. Diese Datei kannst du sichern, kopieren oder in ein anderes System mitnehmen. Das ist angenehm, weil du keinen separaten Datenbankdienst starten musst. Gleichzeitig ist genau das auch eine Einschränkung: SQLite ist nicht dafür gedacht, dass viele Clients gleichzeitig komplexe Schreibzugriffe durchführen wie bei einer typischen Server-Datenbank.

In Java sieht eine Verbindung zum Beispiel so aus:

String url = "jdbc:sqlite:app.db";

Der Unterschied zu H2 im In-Memory-Modus ist hier direkt sichtbar. SQLite arbeitet normalerweise persistent, also dauerhaft. Wenn du Daten speicherst, liegen sie in der Datei und sind nach dem Neustart noch da. Das macht SQLite für kleine lokale Anwendungen deutlich sinnvoller als eine reine In-Memory-Lösung.

Wichtig ist auch der technische Blick: H2 ist stark auf das Java-Ökosystem zugeschnitten. SQLite ist sprachunabhängiger und in sehr vielen Umgebungen verbreitet. Wenn du also in einem reinen Java-Projekt schnell testen willst, ist H2 oft bequemer. Wenn du eine kleine lokale Datenbankdatei brauchst, die du direkt mit deiner Anwendung mitgeben kannst, ist SQLite oft die passendere Wahl.

Die wichtigsten Unterschiede in der Praxis

Für Anfänger ist meistens nicht die Theorie der Knackpunkt, sondern die Frage: Wann nehme ich was? Genau da hilft ein klarer Blick auf die Unterschiede.

Der erste große Unterschied ist die Lebensdauer der Daten. Bei einer In-Memory-Datenbank sind die Daten nur solange vorhanden, wie der Prozess läuft. Sobald die Anwendung stoppt, ist alles weg. Das ist super für Unit-Tests, Integrationstests oder kleine Beispiele. SQLite speichert dauerhaft in einer Datei. Damit eignet sie sich besser, wenn Daten auch morgen noch da sein sollen.

Der zweite Unterschied ist der Einsatzzweck. H2 wird im Java-Alltag oft als Entwicklungs- oder Testdatenbank genutzt. Du kannst damit schnell Tabellen anlegen, SQL ausprobieren oder JPA-Mappings testen. SQLite ist eher eine kompakte echte Datenspeicherung für lokale Anwendungen. Wenn du zum Beispiel ein kleines Java-Tool baust, das Einstellungen, Notizen oder importierte Daten lokal ablegt, ist SQLite oft naheliegender.

Der dritte Unterschied betrifft das Verhalten gegenüber anderen Datenbanksystemen. H2 ist praktisch, aber sie verhält sich nicht in allen Details genauso wie eine produktive Datenbank. SQL-Syntax, Datentypen oder spezielle Funktionen können sich unterscheiden. Das ist wichtig, weil Tests mit H2 gut funktionieren können, obwohl später mit einer anderen Datenbank Probleme auftauchen. SQLite hat ebenfalls eigene Besonderheiten. Ein bekanntes Beispiel ist das flexible Typsystem, das am Anfang einfacher wirkt, später aber auch zu Missverständnissen führen kann.

Gerade deshalb solltest du H2 oder SQLite nicht automatisch als perfekten Ersatz für jede spätere Produktivdatenbank sehen. Für Grundlagen, lokale Entwicklung und einfache Anwendungen sind beide sehr nützlich. Für realistische Produktionstests musst du aber immer im Hinterkopf behalten, dass sich Datenbanken im Detail unterschiedlich verhalten.

Ein realistisches Beispiel ist ein kleines Lernprojekt mit JPA und Maven. Wenn du einfach nur verstehen willst, wie Entities, Repositories und SQL zusammenarbeiten, ist H2 im Speicher oft die schnellste Lösung. Wenn du dagegen ein kleines Desktop-Tool baust, das eine lokale Aufgabenliste dauerhaft speichern soll, ist SQLite meistens die bessere Wahl.

Fazit

H2, In-Memory und SQLite meinen also nicht dasselbe.

Außerdem sind H2 und SQLite nicht die einzigen einfachen Optionen. Es gibt weitere leichte Datenbanken wie HSQLDB oder Apache Derby. Für einen Grundlagenbeitrag ist der Fokus auf H2, In-Memory und SQLite trotzdem sinnvoll, weil du daran die wichtigsten Konzepte direkt siehst: Produkt gegen Betriebsart, flüchtige Daten gegen dauerhafte Speicherung und Java-nahe Entwicklung gegen dateibasierte lokale Persistenz. H2 ist eine konkrete Datenbank, die sowohl im Speicher als auch dateibasiert laufen kann. In-Memory beschreibt nur, dass Daten im RAM liegen und beim Beenden verschwinden. SQLite ist ebenfalls eine konkrete Datenbank, speichert aber normalerweise dauerhaft in einer Datei.

Für Tests, kurze Demos und schnelle Java-Experimente ist H2 im In-Memory-Modus oft sehr angenehm. Für kleine lokale Anwendungen mit echter Persistenz ist SQLite häufig die sinnvollere Wahl. Wenn du dir nur eine Sache merkst, dann diese: In-Memory ist kein Produktname, sondern eine Betriebsart. Genau diese Unterscheidung hilft dir dabei, die Begriffe sauber einzuordnen und in deinem Projekt die richtige Entscheidung zu treffen.