Wie Zilliz die Zukunft der Vektordatenbanken erkannte – und für die Produktion entwickelte
Dieser Beitrag ist eine Zusammenfassung des Podcasts mit Innovator Coffee und James Luan, VP of Engineering bei Zilliz.
Bevor generative KI zum Mainstream wurde, wurden Vektordatenbanken nur selten für sich allein diskutiert. Die meiste Aufmerksamkeit galt weiterhin relationalen Datenbanken, Suchmaschinen oder Big-Data-Frameworks. Vektorsuche, falls sie überhaupt zur Sprache kam, fand sich meist in Forschungsarbeiten oder innerhalb von Algorithmusbibliotheken wieder — nicht in Gesprächen über Produktionssysteme.
Doch Vektordatenbanken sind nicht aus dem Nichts entstanden. Sie sind aus einem tiefergehenden Wandel darin hervorgegangen, wie Daten erstellt und genutzt werden. Um 2017–2018 begannen Teams bei Zilliz, immer wieder dasselbe Problem zu beobachten: Unternehmen wollten mit deutlich mehr unstrukturierten Daten arbeiten — Texten, Bildern, Audio, Logs, Nutzerverhalten —, aber ihre bestehenden Werkzeuge waren dafür nicht ausgelegt. Traditionelle Datenbanken und Keyword-Suche konnten diese Daten speichern, waren jedoch nicht gut darin, sie zu verstehen. Exakte Übereinstimmungen handhabten sie gut. Bedeutung und Ähnlichkeit waren eine andere Geschichte.
Vektoren boten eine praktische Möglichkeit, diese Lücke zu schließen. Indem Texte, Bilder und andere Inhalte in Embeddings umgewandelt wurden, wurde Ähnlichkeit zu etwas, das Systeme direkt berechnen konnten. Sobald Daten auf diese Weise repräsentiert wurden, speicherten Datenbanken nicht mehr nur Datensätze. Sie konnten Informationen auf Grundlage von Bedeutung abrufen, nicht nur anhand von Keywords.
Daher stehen Vektordatenbanken zwischen leistungsstarken Modellen und unordentlichen realen Daten und machen unstrukturierte Informationen in großem Maßstab durchsuchbar, vergleichbar und nutzbar.
Wie also schaffte die Vektorsuche den Sprung von der Forschung in die Produktion — und wohin entwickeln sich Vektordatenbanken als Nächstes? In einer aktuellen Folge des englischsprachigen Podcasts Innovator Coffee teilte James Luan, VP of Engineering bei Zilliz, seine Perspektive und stützte sich dabei auf die Gründungsgeschichte des Unternehmens, die Überlegungen hinter Milvus, der Open-Source-Vektordatenbank von Zilliz, sowie die Designprinzipien, die das System geprägt haben.
Von Algorithmen zur Produktion: Die Evolution von Vektordatenbanken
Mit Blick auf die frühen Tage, bevor Vektorsuche produktionsreif wurde, merkt James Luan an, dass die meisten frühen Fortschritte innerhalb großer Technologieunternehmen stattfanden. Projekte wie Metas FAISS legten die technische Grundlage, waren aber Bibliotheken — keine Datenbanken. Ähnliche Vektorsuchsysteme gab es bei Unternehmen wie Microsoft und Spotify, typischerweise für den internen Gebrauch entwickelt und auf spezifische Workloads zugeschnitten. Diese Werkzeuge waren effektiv, aber sie waren nie dafür konzipiert, als universelle, langlebige Systeme betrieben zu werden.
Der Wendepunkt kam, als Vektorsuche von der Forschung in echte Produkte überging. Sobald Teams versuchten, sie in der Produktion einzusetzen, ließen sich Herausforderungen auf Systemebene nicht mehr ignorieren. Skalierbarkeit, Zuverlässigkeit und der tägliche Betrieb waren ebenso wichtig wie die Suchqualität. Unterschiedliche Wege entstanden. Einige Teams bauten Managed Services, die für Online-Inferenz und enge Integration mit großen Sprachmodellen optimiert waren. Andere verfolgten einen breiteren Infrastrukturansatz und integrierten Vektorsuche mit Data Lakes und traditionellen Datenbanken, um Anwendungsfälle im Unternehmensmaßstab zu unterstützen. Aus James’ Sicht ist diese Divergenz eine natürliche Phase beim Entstehen jeder neuen Infrastrukturebene.
Als große Sprachmodelle reiften und Anwendungen die Produktion erreichten, erweiterte sich die Rolle von Vektordatenbanken schnell. Frühe Anwendungsfälle konzentrierten sich auf ähnlichkeitsbasierte Abfrage — Empfehlungssysteme, Bildsuche und Content-Matching. In den letzten zwei bis drei Jahren ist Retrieval-Augmented Generation (RAG) zum dominierenden Muster geworden. In RAG-Systemen versorgen Vektordatenbanken Modelle mit relevantem, fundiertem Kontext, ermöglichen Faktenabfragen und helfen, Halluzinationen zu reduzieren.
Diese Rolle wird in agentenbasierten Systemen noch wichtiger. Hier fungieren Vektordatenbanken als Langzeit- oder Nearline-Speicher und unterstützen mehrstufiges Schlussfolgern, Kontextkomprimierung und multimodales Retrieval. James fasst diesen Wandel mit einem einfachen Prinzip zusammen: weniger Struktur, mehr Intelligenz. Mit zunehmenden Modellfähigkeiten können starre Pipelines und umfangreiches Labeling im Vorfeld Systeme ausbremsen. Agenten erzielen bessere Ergebnisse, wenn sie in einem flexiblen semantischen Raum arbeiten und dynamisch entscheiden, wie sie Informationen abrufen und kombinieren.
Gleichzeitig betont James, dass Vektordatenbanken keine Magie sind. Die Retrieval-Qualität hängt ebenso sehr von Data Governance ab wie von Algorithmen. Gut kuratierte, domänenrelevante Daten – und kontinuierliche Evaluation – sind unerlässlich. Embedding-Modelle, Reranker und Retrieval-Strategien entwickeln sich schnell weiter, und Teams, die ihren Stack zu lange nicht neu bewerten, geraten oft ins Hintertreffen.
Über die Inferenz hinaus sieht James, dass Vektordatenbanken eine wachsende Rolle beim Training und bei der Datenvorbereitung spielen. Da multimodale Modelle immer verbreiteter werden, wird die Vektorsuche zunehmend eingesetzt, um große Datensätze über Text, Bilder, Video und PDFs hinweg zu bereinigen, zu deduplizieren und zu kuratieren. Mit der Zeit könnte dies mit Data Lakes zu einer „Vector Lake“-Architektur konvergieren, die Batch-Datenverarbeitung mit Online-Inferenz verbindet.
In dieser längerfristigen Perspektive sind Vektordatenbanken nicht mehr nur Retrieval-Engines. Sie werden zu einer semantischen Schicht, die Training, Inferenz und langfristige Data Governance überspannt – und den gesamten Lebenszyklus von KI-Systemen unterstützt.
Wie Zilliz seine Richtung fand, bevor Vektordatenbanken zum Mainstream wurden
James beschreibt die Anfangszeit von Zilliz als eine Phase der Exploration statt unmittelbarer Klarheit. Sowohl er als auch der CEO des Unternehmens kamen aus klassischen Datenbankhintergründen und hatten Jahre damit verbracht, transaktionale Systeme bei Oracle aufzubauen. Von Anfang an wussten sie, dass sie keine weitere konventionelle Datenbank bauen wollten – aber was diese Alternative sein sollte, war noch eine offene Frage.
Ihr erster Versuch war eine GPU-beschleunigte Datenbank, die darauf abzielte, groß angelegte Datenverarbeitung durch spezialisierte Hardware zu beschleunigen. Technisch funktionierte sie. Kommerziell nicht. GPUs lieferten starke Leistung, waren aber teuer, und für die meisten realen Workloads war das Kosten-Leistungs-Verhältnis schwer zu rechtfertigen. Gleichzeitig verbesserten sich CPU-basierte Systeme wie ClickHouse rasant und schlossen einen Großteil der Performance-Lücke zu einem Bruchteil der Kosten.
Diese Erfahrung erzwang ein tieferes Umdenken. Statt zu fragen, wie man Datenbanken schneller machen kann, begann das Team, eine andere Frage zu stellen: welche Arten von Daten wurden noch unzureichend bedient? Traditionelle Analyse- und transaktionale Workloads verfügten bereits über ausgereifte Lösungen. Was hervorstach, waren unstrukturierte Daten – Text, Bilder und andere Inhalte, die Nutzer zunehmend suchen und verstehen wollten, statt sie nur zu speichern.
Der Wendepunkt kam durch Nutzerfeedback. Einige frühe Nutzer fragten, ob das System zur Beschleunigung der Bildsuche eingesetzt werden könne. Diese Frage wies auf eine größere Chance hin: semantische Ähnlichkeit in großem Maßstab, ermöglicht durch Vektorrepräsentationen. Dem Team wurde klar, dass Vektoren – nicht GPUs – die grundlegendere Abstraktion waren. Aus dieser Erkenntnis entstand Milvus als Open-Source-Projekt mit Fokus auf groß angelegte Vektorsuche.
James betont, dass dieser Pivot nicht vom Hype getrieben war. Damals waren „Vektordatenbanken“ keine anerkannte Kategorie, und selbst der Begriff hatte keine klare Definition. Geleitet wurde die Entscheidung von einer Überzeugung, die in Datenbankgrundlagen verwurzelt war: Wenn semantische Suche wichtig werden sollte, würde sie schließlich dieselben Eigenschaften benötigen wie jedes kritische Datensystem – Skalierbarkeit, Stabilität und Zuverlässigkeit.
Diese Entscheidung gab die Richtung für alles vor, was folgte. Indem Zilliz sich früh dazu bekannte, Vektoren als erstklassige Daten und Datenbanken als langlebige Systeme zu behandeln, positionierte sich das Unternehmen vor dem Wandel der Branche hin zu KI-getriebenen Anwendungen – lange bevor dieser Wandel weithin sichtbar wurde.
Als Modelle später von der Forschung in die Produktion übergingen, wurden Vektordatenbanken zu einem zentralen Bestandteil von Enterprise-AI-Architekturen und unterstützten RAG-Pipelines, Agentensysteme, multimodale Suche und die Deduplizierung von Trainingsdaten in großem Maßstab. Mit dieser Ausweitung kamen neue Erwartungen. Geschwindigkeit allein reichte nicht mehr aus. Genauigkeit, Skalierbarkeit, Kosteneffizienz, Data Governance und Sicherheit wurden allesamt zu zentralen Anliegen.
James’ Fazit ist, dass der Aufbau von Systemen, die diese Anforderungen ausbalancieren, kein kurzfristiges Optimierungsproblem ist. Er erfordert Geduld, kontinuierliche Engineering-Investitionen und ein langfristiges Engagement für grundlegende Infrastrukturprinzipien—weit über die anfängliche Begeisterung für eine neue Kategorie hinaus.
Technische Herausforderungen und Lösungen: Vektordatenbanken in der Produktion betreiben
Als Vektordatenbanken in echte produktive AI-Systeme übergingen, argumentiert James, ging es beim Erfolg nicht mehr um reine Rohleistung. In frühen Implementierungen zählte Geschwindigkeit mehr als alles andere. Doch als große Sprachmodelle ins Spiel kamen, wurde die eigentliche Herausforderung der Aufbau von Systemen, die nachhaltig skalieren konnten—und gleichzeitig Kosten, Genauigkeit, Zuverlässigkeit und Unternehmensanforderungen ausbalancierten.
Kosten: Über die reine In-Memory-Suche hinausgehen
James weist darauf hin, dass frühe Vektorsuchsysteme stark auf In-Memory-Indizes angewiesen waren. Dieser Ansatz funktionierte, solange Datensätze klein waren, wurde jedoch wirtschaftlich untragbar, als LLM-getriebene Anwendungen die Datenmengen deutlich erhöhten. In diesem Maßstab ist es weit weniger wichtig, die Latenz um einige Millisekunden zu reduzieren, als die Speicherkosten zu kontrollieren.
Die Lösung ist ein mehrstufiger Ansatz für Speicherung und Indexierung. Durch die Kombination von In-Memory-, festplattenbasierten und Object-Storage-Indizes können Vektordatenbanken die Speicherkosten um bis zu das 100-Fache senken. Dieser Wandel optimiert nicht nur bestehende Workloads—er macht Retrieval in großem Maßstab überhaupt erst praktikabel.
Skalierbarkeit und Stabilität im realen Maßstab
Kostendruck legt schnell Skalierungsgrenzen offen. James merkt an, dass viele Teams mit einfachen Single-Node-Setups beginnen, weil sie leicht bereitzustellen sind. Probleme treten später auf, wenn die Daten in kurzer Zeit um das 10-, 50- oder sogar 100-Fache wachsen.
Diese Realität veranlasste Zilliz dazu, Milvus als verteiltes, cloud-natives System neu aufzubauen. Für James ist Skalierbarkeit untrennbar mit Stabilität verbunden. Ein System, das skalieren kann, aber unter realen Workloads unvorhersehbar ausfällt, ist keine brauchbare Infrastruktur.
Er betont, dass Stabilität oft der schwierigste Teil dabei ist, Vektorsuche in ein Produktionssystem zu verwandeln. Mit bestehenden Open-Source-Tools können viele Teams in sechs bis zwölf Monaten einen funktionierenden Prototyp bauen. Schwierig ist es, dieses System über lange Zeiträume hinweg zuverlässig arbeiten zu lassen, während sich Datenvolumen, Abfragemuster und betriebliche Komplexität verändern.
Anders als Performance-Optimierung entsteht Stabilität nicht durch einen einzelnen Durchbruch. Performance-Gewinne sind sichtbar—Benchmarks können innerhalb weniger Monate eine Verbesserung von 20% oder 30% zeigen. Stabilität wird anders aufgebaut. Jede Korrektur verbessert das SLA möglicherweise nur um den Bruchteil eines Prozents, für sich genommen kaum wahrnehmbar. Doch durch Hunderte kleiner, kumulativer Verbesserungen wird ein System allmählich zuverlässig genug, um als langfristige Infrastruktur betrieben zu werden.
Genauigkeit: Retrieval setzt die Obergrenze
In RAG- und Agentensystemen bestimmt die Retrieval-Qualität direkt die Modellleistung. Wenn das System die richtigen Informationen nicht findet, hat das Modell keine Möglichkeit, dies auszugleichen.
James betont, dass Genauigkeit nicht nur ein Datenbankthema ist. Sie hängt vom gesamten Retrieval-Stack ab, einschließlich Embedding-Modellen, Reranking-Strategien und Datenqualität. Da sich diese Komponenten schnell weiterentwickeln, müssen Teams ihre Setups regelmäßig neu bewerten—oft alle paar Monate—, um die Genauigkeit über die Zeit aufrechtzuerhalten.
Wie Zilliz Open Source und Geschäft ausbalanciert
Im vergangenen Jahr oder in den vergangenen zwei Jahren hat James viel Zeit damit verbracht, über eine Herausforderung nachzudenken, die bei Open-Source-Unternehmen immer wieder aufkommt: wie man eine aktive Open-Source-Community aufbaut und erhält und gleichzeitig ein wachsendes Geschäft betreibt.
Open Source und kommerzielle Ziele stimmen nicht immer sauber überein. Open-Source-Projekte hängen von Offenheit, langfristiger Beteiligung und dem Vertrauen der Community ab, während ein Unternehmen Umsatzziele und Wachstumsbeschränkungen steuern muss. In den letzten Jahren ist dieses Missverhältnis in der gesamten Branche sichtbarer geworden. James hat erlebt, wie mehrere Teams ihre Open-Source-Projekte in den Wartungsmodus versetzt haben – nicht, weil die Technologie nicht mehr funktionierte, sondern weil das Open-Source-Modell mit dem Wachstum des Unternehmens schwer zu unterstützen wurde.
Für Zilliz ist Open Source jedoch nicht nur eine technische Entscheidung – es ist auch eine Go-to-Market-Entscheidung. In der Praxis funktioniert es ähnlich wie eine hochgradig technische kostenlose Testversion – eine Möglichkeit für Entwickler, ein Produkt durch echte Nutzung zu entdecken, zu evaluieren und Vertrauen darin zu gewinnen. Das ist besonders wichtig für Startups, bei denen es schwierig ist, frühe Nutzer zu gewinnen. Für ein engineering-getriebenes Team wie Zilliz erwies sich dies als weitaus effektiver als traditionelle Marketing- oder vertriebsorientierte Ansätze.
Durch die Open-Source-Veröffentlichung von Milvus konzentrierte sich das Team auf GitHub als primären Einstiegspunkt. Entwickler nutzten Milvus in realen Workloads, gaben Feedback und trugen Verbesserungen zum Projekt bei. Im Laufe der Zeit entstand dadurch eine enge Feedbackschleife zwischen Nutzern, der Community und der Produktentwicklung.
Die Ergebnisse waren greifbar. James merkt an, dass etwa 80 % der Kunden von Zilliz Cloud ursprünglich Nutzer des Open-Source-Projekts Milvus waren. Open Source diente zudem als wirkungsvoller Vertrauensmechanismus – Teams, die Milvus selbst betrieben hatten, fühlten sich später deutlich wohler dabei, ein kommerzielles Angebot zu übernehmen.
Dieser Übergang war jedoch nie automatisch. James stellt klar, dass Open Source allein kein Unternehmen schafft. Ein kommerzielles Produkt muss mehr leisten, als Open Source nur zu paketieren – es muss Probleme lösen, die die Open-Source-Version nicht löst. Für Zilliz liegt dieser Mehrwert darin, Milvus zuverlässig im großen Maßstab zu betreiben – Upgrades zu verwalten, Ausfälle zu bewältigen und Leistung sowie Kosten kontinuierlich zu optimieren.
Ein wichtiges Ergebnis dieses Ansatzes ist, dass viele Nutzer feststellen, dass ihre Gesamtkosten nach dem Wechsel zum verwalteten Angebot sinken. Vektordatenbanken entwickeln sich schnell weiter, angetrieben durch Fortschritte bei Indexierung, Quantisierung und Speicherung. Mit Zilliz Cloud profitieren Nutzer kontinuierlich von diesen Verbesserungen, ohne selbst die Last von Upgrades oder Infrastrukturmanagement übernehmen zu müssen.
Aus James’ Sicht ist dieses Gleichgewicht das, was das Modell nachhaltig macht. Open Source schafft Zugang und Vertrauen. Das kommerzielle Angebot verwandelt langfristige Infrastrukturfortschritte in praktischen Mehrwert – ohne die Offenheit zu untergraben, die die Nutzer ursprünglich angezogen hat.
Wie sich Zilliz in einem überfüllten Markt abhebt
Auf die Frage, wie der Markt für Vektordatenbanken heute aussieht, räumt James ein, dass die schnelle Einführung von KI den Markt rasch überfüllt hat. Er umfasst inzwischen verwaltete Dienste, leichtgewichtige Plugins und eine wachsende Zahl neuer Anbieter, die Vektorsuchfunktionen anbieten. Oberflächlich betrachtet erscheinen viele dieser Lösungen ähnlich.
Nach James’ Ansicht wird der wirkliche Unterschied nicht durch Feature-Checklisten bestimmt, sondern durch die Tiefe und Reife der zugrunde liegenden Systeme. Eine grundlegende Vektorsuchfunktion zu entwickeln, ist relativ unkompliziert. Ein System zu bauen, das über lange Zeiträume hinweg zuverlässig im großen Maßstab betrieben werden kann, ist es nicht.
Systemreife
Der Vorteil von Zilliz beginnt mit Systemreife – insbesondere Skalierbarkeit, Stabilität und Kostenkontrolle. Von Anfang an wurde Milvus als verteilte, Kubernetes-native Datenbank konzipiert, die stabil bleibt, wenn Datenmengen um ein Vielfaches wachsen. Das ist wichtig, weil Vektor-Workloads selten reibungslos skalieren. Systeme, die in kleinem Maßstab gut funktionieren, geraten oft ins Straucheln, sobald die Nutzung dauerhaft, sprunghaft und unvorhersehbar wird.
Kosten sind ebenfalls Teil dieser Reife. Zilliz investierte früh in Multi-Tier-Indexierung, die Speicher, Festplatten und Objektspeicher kombiniert. Dies gibt Nutzern praktische Flexibilität, um Leistung und Kosten bei sich entwickelnden Workloads auszubalancieren, anstatt sie auf einen einzigen, teuren Betriebsmodus festzulegen.
Enterprise-Readiness
Enterprise-Readiness ist ein weiteres zentrales Unterscheidungsmerkmal. James kontrastiert Zilliz mit Teams, die hauptsächlich aus modell- oder KI-zentrierten Hintergründen kommen. Die Wurzeln von Zilliz im traditionellen Datenbank-Engineering führten zu frühen Investitionen in Funktionen wie Zugriffskontrolle, Datenisolierung, BYOC-Bereitstellungen, Verschlüsselung und Compliance.
Diese Funktionen sind im Enterprise-Maßstab nicht optional. Sie sind das, was es Vektordatenbanken ermöglicht, über Experimente von Entwicklern hinauszugehen und in regulierte Umgebungen wie Finanzwesen, Gesundheitswesen und große Organisationen mit strengen Sicherheits- und Governance-Anforderungen vorzudringen.
Operative Zuverlässigkeit
James merkt an, dass viele Teams die langfristige operative Komplexität von Vektordatenbanken unterschätzen. Frühe Systeme funktionieren in kontrollierten Umgebungen möglicherweise gut, aber die wirklichen Herausforderungen treten auf, sobald Daten schnell wachsen, die Parallelität zunimmt und KI-Anwendungen in den kontinuierlichen Produktivbetrieb übergehen.
Die meisten Unternehmen möchten ihre Zeit und Ressourcen nicht in den Betrieb komplexer Infrastruktur investieren, insbesondere nicht in hochspezialisierten Bereichen wie der Vektorsuche. Hier sieht James die Rolle von Zilliz: die operative Last des Betriebs von Vektordatenbanken in großem Maßstab zu übernehmen, damit sich Teams auf die Entwicklung von Anwendungen konzentrieren können, statt Infrastruktur zu warten. Mit zunehmender Reife des Marktes wird diese Arbeitsteilung immer wichtiger.
Ausblick: Die nächste Phase der Vektordatenbanken
Mit Blick auf die nächsten drei bis fünf Jahre nimmt James eine pragmatische Sicht darauf ein, wohin sich die Branche entwickelt. Das Wachstum wird weitergehen, aber die zentrale Frage wird nicht mehr sein, ob Vektordatenbanksysteme gebaut werden können – sondern ob sie nachhaltig betrieben werden können. Wenn Modelle größer werden und KI-Anwendungen tiefer in die Produktion vordringen, werden die Datenmengen schnell zunehmen, wodurch die Anforderungen an Kostenkontrolle, Zuverlässigkeit, Genauigkeit und Sicherheit steigen.
In diesem Umfeld wird die Fähigkeit, Kosten um eine Größenordnung zu senken, ohne die Qualität des Retrievals zu beeinträchtigen, zu einem entscheidenden Maßstab. James glaubt, dass hier dauerhafte Vorteile entstehen. Langfristige Marktführer im Bereich der Vektordatenbanken werden nicht durch Funktionen oder Hype bestimmt, sondern durch Infrastrukturdiziplin – die Fähigkeit, groß angelegte Systeme effizient, zuverlässig und über längere Zeit zu betreiben.
Um die vollständige Diskussion zu hören, finden Sie die Episode auf Spotify, Apple Podcasts und YouTube.
Weiterlesen
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Zilliz Cloud Now Available in AWS Europe (Ireland)
Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.