MariaDB Vector: KI-Suche direkt in eurer relationalen Datenbank einbauen

„Brauchen wir jetzt auch noch eine separate Vektordatenbank für unsere KI-Features?“ Diese Frage hören wir in Projekten ständig. Die Antwort seit MariaDB 11.8 LTS: Nein. Mit MariaDB Vector speichert und durchsucht ihr Embeddings direkt dort, wo eure restlichen Daten liegen – in der relationalen Datenbank, die ihr kennt.

Mit über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting begleiten wir bei Never Code Alone Teams bei der Integration moderner KI-Funktionen in bestehende Anwendungen. MariaDB Vector ist dabei ein echter Gamechanger, weil es die Infrastruktur-Komplexität drastisch reduziert.

1. Was ist MariaDB Vector und warum lohnt sich der Einsatz?

MariaDB Vector erweitert den bekannten MariaDB Server um native Vektorsuche. Statt Embeddings in einer separaten Datenbank wie Pinecone, Weaviate oder Milvus zu speichern, legt ihr sie direkt neben euren Produktdaten, Kundenprofilen oder Content ab.

Die Technik dahinter: Ein dedizierter VECTOR-Datentyp speichert Fließkommazahlen in beliebig vielen Dimensionen. Ein spezialisierter VECTOR INDEX ermöglicht dann schnelle Ähnlichkeitssuchen. Der Indexing-Algorithmus basiert auf einer modifizierten HNSW-Implementierung (Hierarchical Navigable Small Worlds), die sich in Benchmarks als performant und skalierbar erwiesen hat.

Für eure Projekte bedeutet das konkret: Ihr müsst keine zweite Datenbank betreiben, keine Daten synchronisieren und keine zusätzliche Infrastruktur verwalten. Eine einzige SQL-Query kombiniert relationale Filter mit semantischer Suche.

2. Wie unterscheidet sich MariaDB Vector von spezialisierten Vektordatenbanken?

Spezialisierte Vektordatenbanken wie Pinecone oder Qdrant wurden von Grund auf für einen Zweck gebaut: Vektorsuche. Sie bieten oft ausgefeilte Features für diesen spezifischen Use Case. Aber sie bringen auch Nachteile mit sich.

Das offensichtlichste Problem: Eure Daten liegen plötzlich an zwei Orten. Produktinformationen in MariaDB, deren Embeddings in Pinecone. Wenn sich ein Produkt ändert, müsst ihr beide Systeme aktualisieren. Konsistenz wird zum echten Problem – besonders bei hohem Transaktionsvolumen.

MariaDB Vector löst das elegant. Embedding und Produktdaten leben in derselben Zeile, derselben Transaktion, demselben Backup. ACID-Compliance gilt für beides. Und ihr nutzt eine Technologie, die eure Teams bereits kennen.

Im Vergleich zu pgvector in PostgreSQL bietet MariaDB einen wesentlichen Vorteil: Die Vektorsuche ist kein Plugin, sondern Teil des Cores. Zusätzlich zeigen aktuelle Benchmarks von Small Datum LLC, dass MariaDB bei Multi-Threaded-Queries oft die doppelte Performance erreicht.

3. Welche Embedding-Modelle lassen sich mit MariaDB Vector nutzen?

Die kurze Antwort: Alle. MariaDB Vector ist agnostisch gegenüber dem Modell, das eure Embeddings generiert. OpenAI GPT-4, Claude, Llama, Mistral, Sentence Transformers von Hugging Face – solange das Modell einen Vektor aus Fließkommazahlen ausgibt, könnt ihr diesen speichern.

Wichtig ist nur, dass ihr bei der Tabellendefinition die richtige Dimension angebt. OpenAIs text-embedding-3-small liefert 1536 Dimensionen, text-embedding-3-large kommt mit 3072. Ein typisches Sentence-Transformer-Modell nutzt oft 384 oder 768 Dimensionen.

CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(256),
    description TEXT,
    embedding VECTOR(1536) NOT NULL,
    VECTOR INDEX (embedding) DISTANCE=cosine
) ENGINE=InnoDB;

In der Praxis empfehlen wir, mit kleineren Modellen zu starten. Die all-MiniLM-L6-v2 von Sentence Transformers läuft lokal, kostet nichts und liefert für viele Use Cases ausreichend gute Ergebnisse. Später könnt ihr immer noch auf größere Modelle wechseln.

4. Wie performant ist die HNSW-Implementierung in MariaDB?

Die Performance-Frage ist berechtigt – schließlich wollt ihr wissen, ob MariaDB Vector für eure Workloads taugt. Die Benchmarks sind vielversprechend.

MariaDB nutzt eine modifizierte HNSW-Implementierung. HNSW baut einen hierarchischen Graphen auf, in dem ähnliche Vektoren durch Kanten verbunden sind. Suchanfragen navigieren durch diesen Graphen und finden effizient die nächsten Nachbarn, ohne jeden einzelnen Vektor vergleichen zu müssen.

In Tests mit dem MNIST-Datensatz erreicht MariaDB Vector vergleichbare Single-Thread-Performance wie etablierte Vektordatenbanken. Der eigentliche Vorteil zeigt sich bei parallelen Zugriffen: Bei Multi-Threaded-Workloads skaliert MariaDB besser als viele Konkurrenten.

Für die Praxis heißt das: Bei typischen Webanwendungen mit vielen gleichzeitigen Nutzern profitiert ihr von dieser Skalierbarkeit. Einzelne, isolierte Suchen sind vielleicht nicht schneller – aber 50 gleichzeitige Anfragen bewältigt MariaDB effizienter.

5. Wie integriert ihr MariaDB Vector in PHP- und Symfony-Anwendungen?

Die Integration in bestehende PHP-Projekte ist unkompliziert. Da MariaDB Vector normales SQL nutzt, funktionieren eure gewohnten Datenbankverbindungen ohne Änderung.

Für Symfony-Projekte mit Doctrine empfehlen wir einen pragmatischen Ansatz: Nutzt Native Queries für die Vektoroperationen. Doctrine unterstützt den VECTOR-Typ nicht nativ, aber ihr könnt problemlos Raw SQL ausführen.

$sql = "SELECT id, name, 
        VEC_DISTANCE_COSINE(embedding, VEC_FromText(:queryVector)) AS distance 
        FROM products 
        ORDER BY distance ASC 
        LIMIT 10";

$stmt = $connection->prepare($sql);
$stmt->bindValue('queryVector', json_encode($embedding));
$results = $stmt->executeQuery()->fetchAllAssociative();

Das Embedding selbst generiert ihr über einen API-Call an euer gewähltes Modell oder mit einer lokalen Lösung wie dem PHP-Client für Ollama. Die zurückgegebenen Produkte sind dann semantisch ähnlich zur Suchanfrage – nicht nur keyword-basiert.

6. Welche Distanzfunktionen bietet MariaDB Vector für Ähnlichkeitssuchen?

MariaDB Vector unterstützt zwei Distanzfunktionen: Euklidische Distanz und Kosinus-Distanz. Die Wahl hängt von eurem Use Case und dem Embedding-Modell ab.

VEC_DISTANCE_EUCLIDEAN berechnet die geometrische Distanz zwischen zwei Punkten im Vektorraum. Kleine Werte bedeuten hohe Ähnlichkeit. Diese Metrik eignet sich gut für Bildsuche oder wenn die absolute Größe der Vektoren relevant ist.

VEC_DISTANCE_COSINE misst den Winkel zwischen Vektoren, unabhängig von ihrer Länge. Das ist der Standard für Textsuche, weil Textembeddings oft normalisiert sind und der Winkel die semantische Ähnlichkeit besser widerspiegelt als die absolute Distanz.

-- Für Textsuche: Kosinus-Distanz
SELECT name FROM products 
ORDER BY VEC_DISTANCE_COSINE(embedding, VEC_FromText('[0.1, 0.2, ...]'))
LIMIT 10;

-- Für Bildsuche: Euklidische Distanz
SELECT image_path FROM images 
ORDER BY VEC_DISTANCE_EUCLIDEAN(embedding, VEC_FromText('[0.3, 0.1, ...]'))
LIMIT 10;

Wichtig: Die Distanzfunktion muss zum Index passen. Wenn ihr den Index mit DISTANCE=cosine erstellt habt, nutzt VEC_DISTANCE_COSINE für optimale Performance.

7. Lassen sich relationale Abfragen und Vektorsuche kombinieren?

Genau hier liegt der größte Vorteil gegenüber spezialisierten Vektordatenbanken. Ihr könnt in einer einzigen Query relationale Filter und semantische Suche kombinieren.

Stellt euch einen E-Commerce-Shop vor: Ein Kunde sucht nach „bequemer Bürostuhl unter 500 Euro“. Die Vektorsuche findet semantisch passende Produkte zu „bequemer Bürostuhl“. Gleichzeitig filtert ihr nach Preis, Verfügbarkeit und Kategorie – alles in derselben Query.

SELECT p.name, p.price, p.description
FROM products p
WHERE p.category = 'office-furniture'
  AND p.price < 500
  AND p.in_stock = 1
ORDER BY VEC_DISTANCE_COSINE(p.embedding, VEC_FromText(:searchEmbedding))
LIMIT 10;

Bei separaten Systemen müsstet ihr erst die Top-100 semantisch ähnlichsten Produkte aus der Vektordatenbank holen, dann gegen eure relationale Datenbank filtern. Das ist umständlich, langsam und fehleranfällig. MariaDB Vector macht das in einem Schritt.

8. Wie viele Dimensionen unterstützt MariaDB Vector maximal?

Die theoretische Grenze liegt bei der Speicherkapazität eurer Datenbank. Praktisch haben wir Vektoren mit bis zu 4096 Dimensionen problemlos getestet. OpenAIs größtes Embedding-Modell liefert 3072 Dimensionen – das funktioniert reibungslos.

Mehr Dimensionen bedeuten allerdings höheren Speicherverbrauch und längere Indexierungszeiten. Jede Dimension belegt 4 Bytes (32-bit Float). Ein Vektor mit 1536 Dimensionen braucht also etwa 6 KB. Bei einer Million Einträgen sind das rund 6 GB für die Embeddings allein.

Unsere Empfehlung: Startet mit dem kleinsten Modell, das eure Qualitätsanforderungen erfüllt. 384 Dimensionen von all-MiniLM-L6-v2 reichen für viele semantische Suchszenarien. Wechselt erst zu größeren Modellen, wenn die Suchqualität nachweislich nicht ausreicht.

MariaDB nutzt übrigens int16 für interne Indexberechnungen, was 15 Bit für den Wert gibt – mehr als die 10 Bit von float16. Das ist ein subtiler, aber relevanter Präzisionsvorteil gegenüber manchen Konkurrenten.

9. Wie aufwändig ist die Migration von pgvector oder anderen Vektordatenbanken?

Die Migration hängt stark von eurem aktuellen Setup ab. Von pgvector auf MariaDB Vector ist der Aufwand überschaubar, weil beide SQL-basiert arbeiten.

Die grundlegende Struktur bleibt gleich: Ihr habt eine Spalte mit Embeddings und einen spezialisierten Index. Die Syntax unterscheidet sich leicht – pgvector nutzt :: für Typkonvertierung, MariaDB nutzt VEC_FromText(). Die Distanzoperatoren heißen anders, folgen aber der gleichen Logik.

-- pgvector
SELECT * FROM items ORDER BY embedding <=> '[0.1, 0.2]' LIMIT 10;

-- MariaDB Vector
SELECT * FROM items ORDER BY VEC_DISTANCE_COSINE(embedding, VEC_FromText('[0.1, 0.2]')) LIMIT 10;

Von spezialisierten Vektordatenbanken wie Pinecone oder Weaviate ist die Migration komplexer. Diese Systeme haben eigene APIs und Datenmodelle. Ihr müsst die Embeddings exportieren, in MariaDB importieren und eure Anwendungslogik anpassen. Der Aufwand lohnt sich aber langfristig durch reduzierte Infrastruktur-Komplexität.

10. Welche Framework-Integrationen gibt es für LangChain, Spring AI und andere KI-Tools?

MariaDB Vector hat sich schnell in die wichtigsten KI-Frameworks integriert. Für Python-Entwickler gibt es offizielle LangChain-Integration über langchain-mariadb. Für Node.js existiert ein LangChain.js-Connector. Java-Teams nutzen LangChain4j oder Spring AI.

Die Spring-AI-Integration ist besonders elegant:

@Autowired
VectorStore vectorStore;

List<Document> results = vectorStore.similaritySearch(
    SearchRequest.builder()
        .query("semantische Suchanfrage")
        .topK(10)
        .build()
);

Zusätzlich unterstützt MariaDB das Model Context Protocol (MCP) für direkte Integration mit KI-Agenten. Der MariaDB MCP Server ermöglicht Claude, ChatGPT und anderen LLMs den direkten Zugriff auf eure Datenbank – sowohl für klassische SQL-Operationen als auch für Vektorsuche.

LlamaIndex für Python und VectorDBBench für Performance-Tests runden das Ökosystem ab. Egal welchen Stack ihr nutzt, es gibt wahrscheinlich bereits eine Integration.

RAG-Anwendungen mit MariaDB Vector aufbauen

Der häufigste Use Case für Vektorsuche ist Retrieval-Augmented Generation (RAG). Statt ein LLM nur auf sein Trainingswissen zu stützen, reichert ihr Anfragen mit relevantem Kontext aus eurer Datenbank an.

Der Workflow ist straightforward: Nutzeranfrage kommt rein, wird zu einem Embedding umgewandelt, die ähnlichsten Dokumente werden per Vektorsuche gefunden, und diese dienen als Kontext für das LLM.

Mit MariaDB Vector könnt ihr dabei relationale Constraints einbauen. Nur Dokumente anzeigen, auf die der Nutzer Zugriffsrechte hat? Ein einfacher WHERE-Filter. Nur aktuelle Versionen berücksichtigen? Ein JOIN auf eure Versionierungstabelle. Das ist mit separaten Vektordatenbanken deutlich komplizierter umzusetzen.

Praktische Implementierung mit Docker starten

Wollt ihr MariaDB Vector schnell ausprobieren? Mit Docker seid ihr in fünf Minuten startklar:

docker run -p 127.0.0.1:3306:3306 
  --name mdb_vector 
  -e MARIADB_ROOT_PASSWORD=Password123! 
  -d mariadb:11.8

Dann verbindet ihr euch mit eurem gewohnten Client und erstellt eine erste Vektortabelle. Die Dokumentation auf mariadb.com/kb/en/vectors/ führt euch durch die Details.

Für Produktionsumgebungen empfehlen wir, die InnoDB-Buffer-Pool-Größe angemessen zu dimensionieren. Vektorindizes leben im Speicher, und ausreichend RAM macht einen erheblichen Performance-Unterschied.

Beratung für eure KI-Integration

Ihr evaluiert MariaDB Vector für eure Anwendung oder plant die Migration von einer separaten Vektordatenbank? Mit über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting unterstützen wir Teams bei der technischen Umsetzung und Architekturentscheidung.

Schreibt uns an roland@nevercodealone.de – gemeinsam analysieren wir euren Use Case und entwickeln einen pragmatischen Integrationsplan. Ob RAG-System, semantische Produktsuche oder Recommendation Engine: Wir helfen euch, die passende Lösung zu finden.

Never Code Alone – Gemeinsam für bessere Software-Qualität!