Werden Amazon S3 Vectors Vektordatenbanken töten – oder retten?
Vor nicht allzu langer Zeit hat AWS etwas Neues vorgestellt: S3 Vectors. Es ist ihr erster Versuch einer Vektorspeicherlösung, mit der du Vektoreinbettungen für semantische Suche direkt in Amazon S3 speichern und abfragen kannst.
Auf den ersten Blick wirkt es wie eine schlanke Vektordatenbank, die auf kostengünstigem Objektspeicher läuft—zu einem Preispunkt, der im Vergleich zu vielen dedizierten Vektordatenbanklösungen eindeutig attraktiv ist.
amazon s3 vectors.png
Natürlich hat das viele hitzige Einschätzungen ausgelöst. Ich habe Leute in sozialen Medien und in Engineering-Kreisen sagen hören, dass dies das Ende speziell entwickelter Vektordatenbanken bedeuten könnte—Milvus, Pinecone, Qdrant und andere eingeschlossen. Eine steile These, oder?
Als Engineering-Architekt von Milvus und jemand, der viel zu viele späte Nächte damit verbracht hat, über Vektorsuche nachzudenken, muss ich zugeben: S3 Vectors bringt tatsächlich etwas Interessantes mit, insbesondere in Bezug auf Kosten und Integration innerhalb des AWS-Ökosystems. Aber statt Vektordatenbanken zu „töten“, sehe ich es als ergänzenden Baustein im Ökosystem. Tatsächlich liegt seine echte Zukunft wahrscheinlich darin, mit professionellen Vektordatenbanken zusammenzuarbeiten, nicht sie zu ersetzen.
In diesem Beitrag erkläre ich, warum ich das so sehe—aus drei Blickwinkeln: der Technologie selbst, dem, was sie kann und nicht kann, und dem, was sie für den Markt bedeutet.
Eine überraschende Tatsache: Vektorspeicherung kann mehr kosten als LLM-Aufrufe
Vektorsuche ist leistungsstark, hat aber einen gravierenden Haken: Sie ist teuer. Die Rechenanforderungen liegen oft ein bis zwei Größenordnungen höher als bei einer typischen NoSQL-Datenbank. Dieser Unterschied ist nicht nur theoretisch—er zeigt sich in echten Rechnungen.
Ich habe kürzlich mit dem CTO einer beliebten KI-Notiz-App gesprochen, der mir etwas Überraschendes erzählte: Sie geben doppelt so viel für Vektorsuche aus wie für OpenAI-API-Aufrufe. Denk einen Moment darüber nach. Der Betrieb der Retrieval-Schicht kostet sie mehr als die Bezahlung des LLM selbst. Das stellt die übliche Annahme auf den Kopf.
Der ChatGPT-Boom 2022 hat das nur noch deutlicher gemacht. Plötzlich waren Embeddings überall, und Vektordaten wurden zum am schnellsten wachsenden Datentyp in der Public Cloud. Retrieval-Augmented Generation (RAG) war der Treiber—und damit kamen drei Herausforderungen, die neu definierten, was eine Vektordatenbank wie Milvus leisten musste:
Massive Datenexplosion: Workloads sprangen nahezu über Nacht von zig Millionen auf zig Milliarden Vektoren. Das ist kein lineares Wachstum—es ist ein Quantensprung, und er hat die alten Methoden der Datenverarbeitung gesprengt.
Latenztoleranz hat sich verschoben: Da LLMs ohnehin Zeit benötigen, um Antworten zu generieren, wurden Nutzer nachsichtiger gegenüber etwas langsamerem Retrieval. Die Denkweise „sub-10ms Recall um jeden Preis“ war plötzlich weniger wichtig.
Kostensensitivität schoss in die Höhe: Eine Verdopplung oder Verdreifachung des Datenvolumens war nicht nur ein Speicherproblem; sie wurde zu einer finanziellen Krise, wenn man versuchte, mit traditionellen, rechenintensiven Designs zu skalieren.
Kurz gesagt: Vektordatenbanken mussten sich schnell weiterentwickeln, nicht weil die Technologie nicht funktionierte, sondern weil die Ökonomie des Retrievals plötzlich im Mittelpunkt stand.
Die Entwicklung der Vektorspeicherung: Vom Arbeitsspeicher zur Festplatte und jetzt zum Objektspeicher
Der Druck rund um Kosten und Skalierung zwang zu einer Schlussfolgerung: Vektordatenbanken konnten nicht für immer rein arbeitsspeicherbasiert bleiben. Sie mussten sich weiterentwickeln—zuerst auf Festplatten und jetzt auf Objektspeicher wie S3. Das war keine Wahl; es war eine Unvermeidlichkeit für die Branche. Und wenn du den Bereich verfolgt hast, hast du wahrscheinlich denselben Trend bemerkt wie ich in den letzten Jahren.
Ich habe gesehen, wie Vektordatenbanken drei klar unterscheidbare Phasen durchlaufen haben:
Phase I (2018–2022): Die Ära des reinen Arbeitsspeichers: In den frühen Milvus-Tagen stützten wir uns auf speicherbasierte Indizes wie HNSW und IVF. Leistung und Recall waren fantastisch – aber die Kosten waren brutal. Arbeitsspeicher skaliert nicht günstig, und jeder, der diese Cloud-Rechnungen bezahlte, wusste das.
Phase II (2022–2024): Die Revolution der Festplattenindizes: Um den Speicherengpass zu durchbrechen, haben wir einen festplattenbasierten Ansatz mit DiskANN zusammen mit unserem proprietären Cardinal-Index (exklusiv für Zilliz Cloud, das verwaltete Milvus) entwickelt. Mit Tricks wie asynchronem I/O (AIO) und io_uring gelang es uns, echte Leistung aus Festplatten herauszuholen. Das Ergebnis? Eine Kostenreduzierung um das 3- bis 5-Fache. Unsere kapazitätsoptimierten Compute Units (CUs) wurden schnell zu Bestsellern in Zilliz Cloud.
Phase III (2024– ): Die Ära des Tiered Storage: Der nächste Schritt lag auf der Hand: Vektorindizes auf günstigen Objektspeicher verlagern. Neue Akteure wie TurboPuffer setzten voll auf S3 und senkten die Speicherkosten auf ~0,33 $/GB/Monat – eine Reduzierung um das 10-Fache. Doch der Kompromiss war ebenso klar: Latenz bei Cold Queries im Bereich von 500 ms bis 1 s und schwächere Recall-Präzision.
Bei Zilliz arbeiten wir schon seit einiger Zeit an Tiered Storage, haben die Veröffentlichung jedoch zurückgehalten, bis wir die Leistung von Cold Queries in den Griff bekommen konnten. Nächsten Monat werden wir unsere aufgerüsteten CUs mit erweiterter Kapazität und echter Hot/Cold-Trennung in Zilliz Cloud einführen. Das bedeutet stabile Cold-Query-Latenz unter 500 ms, kombiniert mit ultrahohem QPS für Hot Queries. Mit anderen Worten: das Beste aus beiden Welten.
Amazon S3 Vectors kommt genau zum richtigen Zeitpunkt
Da sich Tiered Storage bereits bewährt, ist es keine Überraschung, dass AWS mit S3 Vectors eingestiegen ist. Tatsächlich wirkt die Veröffentlichung wie eine natürliche Erweiterung dessen, was in der Branche ohnehin bereits geschah. Amazon hatte die Rolle von S3 mit Funktionen wie S3 Tables erweitert und es von „nur Objektspeicher“ zu einem multimodalen Cold-Storage-Rückgrat weiterentwickelt. Vektoren sind schlicht die nächste Modalität in dieser Entwicklung – und wahrscheinlich wird es dabei nicht bleiben. Graphen, Key-Value- und Zeitreihendaten könnten alle denselben Weg gehen.
Und Amazon bringt drei unbestreitbare Vorteile mit:
Niedrigere Kosten: eine der niedrigsten Speicherpreisen der Branche.
Massive Skalierung: Die Maschinenpools von AWS können nahezu jede Abfragelast aufnehmen.
Microservice-native Architektur: perfekt abgestimmt auf den Write–Build–Query-Workflow der Vektorindizierung.
Zusammengenommen verleihen diese Faktoren S3 Vectors das Potenzial für eine extrem kostengünstige, hochskalierbare Cold-Storage-Lösung für Vektoren.
S3 Vectors ist ein echter Preiskiller, aber mit klaren Grenzen
Sobald S3 Vectors angekündigt wurde, unterzog unser Team es umfassenden Tests. Die Ergebnisse waren aufschlussreich – nicht nur im Hinblick darauf, wie günstig es ist, sondern auch darauf, wo die Schwachstellen sichtbar werden.
S3 Vectors ist ein echter Preiskiller
Es lässt sich nicht leugnen: S3 Vectors ist unglaublich kosteneffizient.
Speicher kostet nur $0,06/GB, also etwa 5-mal weniger als bei den meisten serverlosen Vektorlösungen. Für eine repräsentative Workload – sagen wir 400 Millionen Vektoren plus 10 Millionen Abfragen pro Monat – beläuft sich die Rechnung auf etwa $1.217/Monat. Das ist eine Reduzierung um mehr als das 10-Fache im Vergleich zu traditionellen Vektordatenbanken. Für Workloads mit niedrigem QPS und hoher Latenztoleranz ist es nahezu unschlagbar.
Aber die Leistung hat echte Einschränkungen
Größenbeschränkungen für Collections: Jede S3-Tabelle ist auf maximal 50 Mio. Vektoren begrenzt, und du kannst nur bis zu 10.000 Tabellen erstellen.
Cold Queries: Die Latenz liegt bei ~500 ms für 1 Mio. Vektoren und ~700 ms für 10 Mio. Vektoren.
Hot Queries: Die Latenz bleibt bei 200 QPS unter 200 ms, aber es ist schwierig, diese Obergrenze von 200 QPS zu überschreiten.
Schreibleistung: Auf unter 2 MB/s begrenzt. Das ist um Größenordnungen niedriger als bei Milvus (das GB/s bewältigt), auch wenn man positiv anmerken muss, dass Schreibvorgänge die Abfrageleistung nicht verschlechtern. Übersetzung: Es ist nicht für Szenarien mit großen, häufig veränderlichen Datensätzen konzipiert.
Kompromisse bei Präzision und Funktionalität
Bei der Präzision wird es kompliziert. Der Recall liegt bei 85–90 %, und es gibt keine Stellschrauben, um ihn höher zu treiben. Kommen Filter hinzu, kann der Recall unter 50 % fallen. In einem Test, bei dem wir 50 % der Daten gelöscht haben, forderten TopK-Abfragen 20 Ergebnisse an, konnten aber nur 15 zurückgeben.
Auch die Funktionalität ist reduziert. TopK-Abfragen sind auf maximal 30 begrenzt. Metadaten pro Datensatz unterliegen strengen Größenbeschränkungen. Und Funktionen wie Hybrid Search, Multi-Tenancy oder erweiterte Filterung sucht man vergeblich—allesamt Must-haves für viele Produktionsanwendungen.
S3 Vectors im Detail: Die wahrscheinliche Architektur
Nachdem wir Tests durchgeführt und sie mit vertrauten AWS-Designmustern abgeglichen haben, haben wir eine ziemlich gute Hypothese entwickelt, wie S3 Vectors unter der Haube funktioniert. Zwar hat Amazon keine vollständigen Details veröffentlicht, doch die Leistungsmerkmale deuten auf fünf Kerntechnologien hin:
SPFresh Dynamic Indexing: Anstatt nach jedem Schreibvorgang ganze Indizes neu aufzubauen, scheint S3 Vectors nur die betroffenen Bereiche zu aktualisieren. Dieses Design hält die Schreibkosten niedrig und die Verfügbarkeit hoch, hat aber seinen Preis: Die Recall-Raten sinken nach Updates um einige Prozentpunkte.
Deep Quantization (4-bit PQ): Um den I/O-Overhead von S3 zu reduzieren, werden Embeddings wahrscheinlich mithilfe von 4-bit Product Quantization komprimiert.
Der Vorteil: Speicher ist günstig, und Abfragen bleiben schnell.
Der Nachteil: Der Recall pendelt sich bei etwa ~85 % ein, und es gibt keine Stellschrauben für Entwickler, um ihn höher zu treiben.
Post-Filter Mechanism: Filterung scheint nach dem groben Retrieval angewendet zu werden. Das hält den Index einheitlich und einfach, tut sich aber mit komplexen Bedingungen schwer. In unseren Tests, als wir 50 % der Daten gelöscht hatten, lieferten TopK-Abfragen, die 20 Ergebnisse anforderten, nur 15 zurück—klassische Anzeichen einer Post-Filter-Pipeline. Das deutet außerdem darauf hin, dass Amazon stark auf bestehende Open-Source-Indexdesigns gesetzt hat, statt ein eigenes von Grund auf neu zu entwickeln.
Multi-Tier Caching: Hot Queries verhalten sich deutlich schneller, wahrscheinlich dank eines SSD/NVMe-Caches vor S3. Wenn eine Abfrage jedoch den Cache verfehlt, steigt die Latenz erheblich. Dieses Muster passt zu einer mehrstufigen Cache-Hierarchie, die darauf ausgelegt ist, die inhärente Trägheit von Object Storage zu kaschieren.
Large-Scale Distributed Scheduling: AWS verfügt über reichlich Maschinenpools. S3 Vectors scheint die Arbeitslast über Microservices zu verteilen und den Ablauf read → decompress → search per Pipelining zu verarbeiten. Das Ergebnis ist das, was wir in Tests beobachtet haben: eine bemerkenswert stabile Latenzverteilung, selbst unter hoher Last.
Wo S3 Vectors passt: Das richtige Werkzeug für bestimmte Aufgaben
Nachdem wir S3 Vectors ausgiebig getestet haben, ist klar, dass es in einigen Szenarien glänzt und in anderen an seine Grenzen stößt. Wie die meisten Infrastruktur-Tools ist es keine Universallösung—es ist das richtige Werkzeug für den richtigen Job.
Wo es gut funktioniert
Archivierung kalter Daten: Perfekt zum Speichern historischer Datensätze, auf die selten zugegriffen wird. Wenn du mit Abfragezeiten von 500 ms+ leben kannst, sind die Kosteneinsparungen unschlagbar.
RAG-Abfragen mit niedrigem QPS: Denk an kleine interne Tools oder Chatbots, die nur Dutzende von Abfragen pro Tag ausführen und unter 100 QPS bleiben. Für diese Anwendungsfälle ist Latenz kein Dealbreaker.
Kostengünstiges Prototyping: Großartig für Proof-of-Concept-Projekte, bei denen das Ziel darin besteht, eine Idee zu testen, ohne viel in Infrastruktur zu investieren.
Wo es Schwierigkeiten hat
Leistungsstarke Suche und Empfehlung: Wenn Ihre Anwendung Latenzen unter 50 ms benötigt, ist S3 Vectors schlicht nicht dafür ausgelegt.
Schreibvorgänge mit hohem Volumen oder häufige Updates: Die Leistung verschlechtert sich schnell, und die Recall-Präzision sinkt bei hoher Änderungsrate merklich.
Komplexe Query-Workloads: Es gibt keine Unterstützung für hybride Suche, Aggregationen oder andere fortgeschrittene Abfragefunktionen.
Multi-Tenant-Produktions-Apps: Mit einer festen Obergrenze von 10.000 Buckets ist es nicht für groß angelegte Multi-Tenant-Bereitstellungen konzipiert.
Mit anderen Worten: S3 Vectors eignet sich hervorragend für kalte, günstige Szenarien mit niedrigen QPS – aber es ist nicht die Engine, mit der Sie ein Empfehlungssystem, eine Echtzeit-Such-App oder ein produktives System in großem Maßstab betreiben möchten.
Die Zukunft ist mehrstufiger Vektorspeicher
S3 Vectors bedeutet nicht das Ende von Vektordatenbanken – es bestätigt etwas, das viele von uns schon seit einiger Zeit beobachten: Die Zukunft ist mehrstufiger Speicher. Anstatt jeden Vektor in teurem Arbeitsspeicher oder auf schnellem Datenträger vorzuhalten, werden sich Workloads ganz natürlich auf Hot-, Warm- und Cold-Tiers verteilen – je nachdem, wie oft darauf zugegriffen wird und welche Latenz die Anwendung tolerieren kann.
So sieht das in der Praxis aus:
Hot Data Layer (<50ms) – Hier befinden sich Echtzeitsuche, Empfehlungen und zielgerichtete Anzeigen. Die Latenz muss unter 50 ms liegen, was bedeutet, dass spezialisierte Vektordatenbanken weiterhin die beste Option sind. Sie sind sowohl für extrem hohe Geschwindigkeit als auch für hohen Query-Durchsatz optimiert.
Warm Data Layer (50–500ms) – Viele RAG-basierte Anwendungen und gemeinsam genutzte Multi-Tenant-Services fallen in diese Kategorie. Diese Workloads benötigen keine ultraniedrige Latenz, aber sie brauchen vorhersehbare Leistung zu geringeren Kosten. S3 Vectors und die Tiered-Storage-Instanzen von Milvus passen gut in diesen Mittelbereich.
Cold Data Layer (>500ms) – Historische Archive und Offline-Analysen erfordern keine Echtzeitantworten, daher ist eine Latenz im Bereich von Hunderten Millisekunden akzeptabel. Entscheidend ist hier Kosteneffizienz in massivem Maßstab. Hier glänzen Lösungen wie S3 + Spark/Daft oder der Milvus Vector Data Lake.
Die Hot–Warm–Cold-Aufteilung balanciert Latenz, Kosten und Skalierbarkeit auf eine Weise aus, die kein einzelner Storage-Tier allein abdecken kann. Dieses Muster haben wir bereits bei relationalen Datenbanken, Data Warehouses und sogar CDNs gesehen – und Vektorspeicher folgt nun derselben Entwicklung. Diese dreistufige Architektur passt außerdem eng zu der Roadmap, die wir für Milvus und Zilliz Cloud entwickeln.
1. Eine einheitliche Online- + Offline-Verarbeitungsarchitektur
KI-Anwendungen leben nicht sauber getrennt in separaten „Online“- und „Offline“-Welten. In Wirklichkeit bewegen sich Daten ständig zwischen beiden. Deshalb werden wir mit dem kommenden Milvus 3.0 einen Vector Data Lake einführen, der darauf ausgelegt ist, sowohl Echtzeit-Retrieval als auch Offline-Verarbeitung aus demselben Datensatz zu unterstützen.
In der Praxis bedeutet das: Ein Datensatz kann Ihre Live-RAG- und Suchanfragen unterstützen und gleichzeitig in Spark-basierte Offline-Analysen einfließen – zum Beispiel zur Kuratierung von Trainingsdaten für LLMs. Keine Duplizierung, kein Jonglieren mit zwei verschiedenen Pipelines.
Wir werden außerdem das StorageV2 format für den Vector Data Lake einführen, das die Wirtschaftlichkeit auf ein neues Niveau hebt:
Bis zu 100x günstiger für Cold-Data-Speicherung.
Bis zu 100x schneller als Brute-Force-Spark-Abfragen auf Hot Data.
Das Ergebnis ist ein einheitliches System, das Redundanz minimiert, Kosten unter Kontrolle hält und die Arbeit mit Vektordaten deutlich weniger mühsam macht.
2. Funktionen entwickeln, die KI-Entwickler tatsächlich brauchen
In den vergangenen zwei Jahren haben sich KI-Anwendungen rasant weiterentwickelt – und ebenso die Anforderungen an die Infrastruktur dahinter. Bei Zilliz haben wir Milvus im Gleichschritt mit diesen Anforderungen vorangebracht und Funktionen wie BM25 + Vektor-Hybridsuche, Multi-Tenant-Isolation, Hot-Cold-Tiered-Storage und MinHash-Deduplizierung ausgeliefert, zusammen mit einer langen Liste entwicklerorientierter Verbesserungen.
Unsere Philosophie war einfach: Wenn man ein tiefes Verständnis geschäftlicher Anwendungsfälle mit der neuesten Technologie verbindet, erschließt man völlig neue Möglichkeiten für Infrastruktur. Diese Denkweise prägt Milvus 3.0, das eine neue Welle KI-nativer Funktionen bringen wird, die direkt für reale Anwendungen entwickelt wurden. Darunter:
Keyword-Gewichtung in der Suche – Damit eine Abfrage wie „rotes Telefon“ rot angemessen priorisieren kann.
Geolocation-Unterstützung – Standortbewusste Vektoren speichern und abfragen, um Prompts wie „finde Cafés in der Nähe“ zu verarbeiten.
Multi-Vector-Unterstützung für RAG – Mehrere Embeddings an jeden Text anhängen, um Recall und Genauigkeit bei komplexen Retrieval-Aufgaben zu verbessern.
Flexible UDF-Verarbeitung – Benutzerdefinierte Funktionen für reichhaltigere, anpassbare Datenverarbeitung.
Tools für visuelle Analysen – Tiefgehenderes Offline-Mining und Datenexploration in großem Maßstab.
Und das ist erst der Anfang. Der wichtigere Punkt ist, dass sich Milvus zu einem System entwickelt, das nicht nur effizient und skalierbar ist, sondern im Kern KI-nativ – speziell dafür gebaut, wie moderne Anwendungen tatsächlich funktionieren.
3. Engineering für Skalierung ohne den hohen Preis
Bei Zilliz glauben wir: Eine 10-fache Kostensenkung öffnet die Tür zu 100-mal mehr Anwendungsfällen. Dieses Prinzip hat jeden großen Meilenstein in Milvus geleitet. Seit 2022 haben wir festplattenbasierte Indizes, GPU-Beschleunigung und RabitQ-Quantisierung eingeführt – all dies hat die Abfrageleistung um Größenordnungen gesteigert und gleichzeitig die Kosten gesenkt.
Mit Blick nach vorn liegt unser Fokus darauf, noch mehr Effizienz aus dem Stack herauszuholen:
Tiefere Hardware-Optimierung – Abstimmung auf reine Rechenleistung und IOPS-Performance.
Intelligentere Komprimierung und Quantisierung – Vektoren schlanker machen, ohne Genauigkeit aufzugeben.
Early Termination für Indexabfragen – Verschwendete Berechnung abbrechen, sobald wir zuverlässige Ergebnisse haben.
Verfeinertes Tiered Indexing – Bessere Cache-Nutzung für schnelleren Zugriff auf kalte Daten.
Das Endziel hat sich nicht geändert: Infrastruktur bauen, die sofort einsatzbereit funktioniert, bei Bedarf skaliert und zugleich schnell und bezahlbar bleibt.
Warum das Aufkommen von S3 Vectors gute Nachrichten für alle ist
Viele Menschen sorgen sich, dass S3 Vectors traditionelle Vektordatenbanken überflüssig machen wird. Meine Einschätzung ist das Gegenteil: Seine Veröffentlichung ist eine gute Nachricht für die gesamte Branche. Tatsächlich sehe ich drei große Vorteile.
Es validiert die Nachfrage. Niemand kann mehr behaupten, Vektoren seien nur ein kurzlebiger Trend. Wenn AWS ein Produkt darum herum entwickelt, ist das der eindeutige Beweis, dass Vektorspeicherung eine echte Notwendigkeit ist – nicht nur „Indizes, die in eine Datenbank verpackt sind“.
Es bildet den Markt weiter. Durch die Reichweite von AWS sind sich nun mehr Unternehmen der Bedeutung von Vektordatenbanken bewusst, was die Grenzen dessen erweitert, welche Anwendungen entwickelt werden können.
Es treibt Innovation voran. Wettbewerb bringt uns alle – Milvus eingeschlossen – dazu, stärker zu optimieren, Kosten weiter zu senken und differenzierte Stärken zu finden.
Aus Positionierungssicht wirkt S3 Vectors weniger wie eine vollständige Vektordatenbank und eher wie die Cold Tier der Vektorspeicherung. Die niedrigen Kosten machen es besonders attraktiv für Szenarien, die zuvor preislich nicht tragbar waren: kleine Teams, die RAG-Apps entwickeln, einzelne Entwickler, die experimentieren, oder Organisationen, die riesige Datensätze mit nur grundlegenden Retrieval-Anforderungen indexieren. Das ist eine echte Freischaltung für das Ökosystem.
Persönlich möchte ich auch das AWS-Engineering-Team würdigen. Sie haben ihre Plattform kontinuierlich verbessert – vom Lambda-Debugging bis hin zur Cold-Start-Performance – und S3 Vectors ist ein weiteres Beispiel für durchdachte Produktinnovation. Ich bin wirklich gespannt zu sehen, was Entwickler nun bauen werden, da die wirtschaftlichen Rahmenbedingungen so günstig sind.
Also nein, der Markt für Vektordatenbanken wird nicht disruptiert – er reift zu einem gestuften Ökosystem heran, in dem unterschiedliche Lösungen unterschiedliche Performance- und Kostenanforderungen bedienen. Das ist gut für Unternehmen, gut für Entwickler und gut für den gesamten AI-Infrastruktur-Stack.
Das goldene Zeitalter der Vektordatenbanken ist nicht vorbei – es fängt gerade erst an.
Weiterlesen
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.