Mengumumkan Milvus 3.0: Pencarian Vektor Lake-Native dan Mesin Retrieval yang Lebih Bertenaga

Hari ini, kami merilis Milvus 3.0, sebuah tonggak arsitektur besar bagi proyek ini. Rilis ini mengubah baik tempat Milvus dapat membangun dan menyajikan indeks maupun seberapa banyak pekerjaan retrieval yang dapat dilakukan langsung di dalam engine.

• Milvus 3.0 memperkenalkan jalur lake-native untuk mengindeks data vektor yang berada di object storage dan format tabel terbuka, termasuk Parquet, Lance, Iceberg, dan Vortex. Tim dapat membuat data yang berada di lake dapat dicari tanpa mempertahankan salinan lain di database vektor.
• Rilis ini juga memperluas Milvus melampaui retrieval kandidat awal. Pengurutan sisi server, agregasi, pencarian berfaset, StructArray untuk struktur dokumen/chunk bertingkat dan vektor ColBERT, serta indeks sparse yang dirancang ulang memindahkan lebih banyak proses pemeringkatan, pengelompokan, dan pemrosesan hasil dari kode aplikasi ke dalam engine retrieval.

Bersama-sama, kemajuan ini menjadikan Milvus fondasi sumber terbuka untuk retrieval AI produksi dan untuk arsitektur Vector Lakebase yang menggabungkan penyimpanan lake-native dengan retrieval vektor berkinerja tinggi.

Sekilas tentang rangkaian fitur Milvus 3.0

Area	Fitur	Mengapa ini penting
Retrieval lake-native	External Collections di atas Parquet, Lance, Iceberg, dan Vortex	Cari data yang berada di lake tanpa mempertahankan salinan serving kedua
Penyimpanan berbasis S3	Loon (Storage v3)	Mengurangi amplifikasi point-read untuk akses bergaya serving dan mendukung evolusi skema
Alur kerja offline/batch dan pemulihan	Snapshots, Spark DataSource V2, dan evolusi skema online	Membawa tampilan koleksi yang stabil ke pipeline evaluasi, deduplikasi, clustering, dan fitur
Engine retrieval	ORDER BY, agregasi, faset, StructArray, dan retrieval sparse yang ditingkatkan	Memindahkan lebih banyak pemrosesan hasil dan penilaian multi-vektor ke Milvus
Model Data & Operasi	Vektor nullable, TEXT LOB, TTL, MinHash, Woodpecker, dan ForceMerge	Mendukung model data yang lebih kaya dan pola operasi produksi

Infrastruktur lake-native: indeks dan sajikan data di tempat data itu sudah berada

Perubahan arsitektur terbesar di Milvus 3.0 adalah tempat sistem dapat membangun dan menyajikan indeks. Data vektor dapat tetap berada dalam format terbuka di object storage sementara Milvus menyediakan pengindeksan, retrieval, dan API kelas produksi.

1. External Collections: mengindeks langsung pada data yang berada di lake

Banyak tim sudah menyimpan embedding di data lake — tabel Lance, tabel Iceberg, file Parquet, atau dataset format terbuka lainnya di S3, GCS, atau Azure Blob Storage. Sebelum Milvus 3.0, biasanya ada dua opsi untuk mencari data tersebut.

• Menyalin embedding ke database vektor. Ini menyediakan pencarian latensi rendah, tetapi membuat salinan kedua dan pipeline ETL yang harus tetap tersinkronisasi.
• Melakukan query langsung ke lake. Ini menghindari duplikasi, tetapi tanpa indeks ANN, pencarian vektor menjadi pemindaian brute-force yang tidak dapat memenuhi latensi produksi.

External Collections memperkenalkan jalur ketiga. Anda mendefinisikan koleksi Milvus di atas data yang tetap berada di object storage, memetakan field eksternal ke skema Milvus, dan menggunakan API pencarian dan query yang sama seperti koleksi native. File sumber tidak berpindah; Milvus membangun dan menyajikan indeks vektor, inverted BM25, JSON, dan skalar di atas data eksternal.

External Collections bersifat read-only dan zero-copy, sehingga berguna ketika tata kelola, batas kepemilikan, atau biaya operasional mengharuskan dataset sumber tetap berada di lake.

Ketika dataset eksternal berubah, Milvus membaca manifest penyimpanannya dan mengindeks fragmen yang baru ditambahkan alih-alih membangun ulang seluruh koleksi.

import json
import os
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(uri=“”)
# Register an Iceberg table as a zero-copy collection.
schema = client.create_schema(
external_source=“s3://lake/docs/metadata/v1.metadata.json”,
external_spec=json.dumps(
{
“format”: “iceberg-table”,
“snapshot_id”: 123456789,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“access_key_id”: os.environ[“AWS_ACCESS_KEY_ID”],
“access_key_value”: os.environ[“AWS_SECRET_ACCESS_KEY”],
},
}
),
)
schema.add_field(field_name=“id”, datatype=DataType.INT64, external_field=“doc_id”)
schema.add_field(field_name=“emb”, datatype=DataType.FLOAT_VECTOR, dim=1024, external_field=“embedding”)
schema.add_field(field_name=“title”, datatype=DataType.VARCHAR, max_length=1024, external_field=“title”)
client.create_collection(collection_name=“docs”, schema=schema)
# Import the external table snapshot.
job_id = client.refresh_external_collection(collection_name=“docs”)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(1)
index_params = client.prepare_index_params()
index_params.add_index(field_name=“emb”, index_type=“HNSW”, metric_type=“COSINE”)
client.create_index(collection_name=“docs”, index_params=index_params)
client.load_collection(collection_name=“docs”)

Untuk lingkungan yang diatur tata kelolanya, retrieval dapat berjalan di tempat data diizinkan berada. Untuk sistem AI berskala besar, dataset yang berada di lake dapat mendukung beberapa deployment retrieval tanpa pekerjaan migrasi di antaranya.

External Collections adalah kemampuan tambahan. Koleksi native Milvus tetap menjadi jalur utama untuk serving yang write-heavy dan latensi rendah, sementara External Collections dirancang untuk dataset yang system of record-nya tetap berada di luar Milvus.

Untuk detail selengkapnya, lihat Create an External Collection.

2. Loon (Storage v3): Point Read yang Efisien untuk Retrieval Lake-Native

External Collections memunculkan pertanyaan yang jelas: object storage dirancang untuk skala dan durabilitas, tetapi apakah ia dapat mendukung point read sempit yang mengikuti pencarian ANN?

Tantangannya adalah amplifikasi baca. Pencarian vektor umumnya berjalan dalam dua tahap: indeks ANN mengembalikan ID kandidat, dan sistem mengambil field terpilih untuk kandidat tersebut. Format yang dioptimalkan untuk pemindaian analitis dapat mengubah lookup logis yang sempit menjadi pembacaan fisik yang jauh lebih besar.

Milvus 3.0 mengatasi masalah ini dengan Loon, juga dikenal sebagai Storage v3, sebuah engine penyimpanan kolumnar berbasis manifest untuk object storage yang kompatibel dengan S3. Loon mengatur field ke dalam ColumnGroups dengan ID baris yang selaras, sehingga field skalar dapat memprioritaskan filtering dan pemindaian sementara vektor serta field yang sering diakses dengan point-read menggunakan layout yang dirancang untuk lookup yang lebih sempit.

Loon memisahkan indeks vektor dan inverted dari format file alih-alih menyematkannya di dalam format tersebut. Setiap versi dataset dijelaskan oleh manifest immutable yang mencatat ColumnGroups-nya, sehingga engine pengindeksan yang sama dapat bekerja di Lance, Parquet, Iceberg, dan Vortex.

Desain manifest juga membuat evolusi skema tidak terlalu mengganggu. Menambah atau menghapus field dapat memperbarui metadata tanpa menulis ulang kolom yang ada. Mengisi field baru menulis ColumnGroup baru sambil membiarkan ColumnGroups yang ada tidak berubah.

Vortex adalah format default untuk jalur ini. Ini adalah format kolumnar terbuka yang kompatibel dengan Arrow, dengan layout fleksibel dan encoding bertingkat yang lebih cocok untuk data AI yang banyak menggunakan point-query. Dalam satu benchmark internal menggunakan 3 juta baris, vektor 128 dimensi, S3, dan 256 pembaca konkuren, I/O terukur per point read turun dari sekitar 9,4 MB untuk baseline Parquet menjadi 0,07 MB untuk Vortex dengan Loon, kira-kira 135 kali lebih kecil.

Milvus 3.0 tidak membuat object storage berperilaku seperti memori lokal. Rilis ini mengurangi amplifikasi baca yang jika tidak ditangani membuat object storage tidak praktis untuk lookup titik bergaya serving. Predicate pushdown ke dalam format dan varian Vortex lokal adalah langkah berikutnya dalam roadmap.

Untuk detail selengkapnya, lihat blog kami: Why We Built Loon dan proyek Vortex.

3. Snapshots: tampilan point-in-time tanpa penyalinan data

Pekerjaan offline membutuhkan tampilan data yang konsisten meskipun koleksi produksi terus menerima penulisan. Snapshot Milvus adalah tampilan read-only point-in-time yang mencatat referensi ke file data, indeks, dan metadata yang sudah ada alih-alih menyalin seluruh dataset.

Hal itu membuat snapshot cukup murah untuk dibuat sebelum operasi berisiko seperti penggantian model, pekerjaan re-embedding, atau migrasi skema. Memulihkan snapshot dapat menggunakan kembali file data dan indeks yang ada melalui penyalinan sisi server di object storage, bukan mengimpor ulang setiap baris dan membangun ulang setiap indeks. Fitur ini sangat berguna untuk workload yang bergerak cepat seperti agen AI, di mana data berubah terus-menerus, dan Anda menginginkan titik pemulihan yang sering dan murah, bukan backup besar sesekali.

Tampilan beku yang sama dapat mendukung evaluasi, deduplikasi, validasi backfill, dan pengujian terisolasi sementara koleksi live terus menerima penulisan. Snapshot menstabilkan input logis, meskipun workload mungkin tetap berbagi infrastruktur seperti object storage dan bandwidth jaringan.

Snapshot tidak menggantikan backup. Snapshot mereferensikan file yang dimiliki oleh koleksi live dan paling cocok untuk pemulihan logis, cloning, dan tampilan stabil berumur pendek. Backup membuat salinan independen untuk retensi jangka panjang dan pemulihan bencana.

Untuk informasi selengkapnya, lihat Snapshots, Manage Snapshots, dan Snapshot Use Cases.

4. Spark connector: menghubungkan Milvus ke alur kerja batch

Snapshot yang stabil hanya berguna jika engine batch dapat membacanya. Milvus 3.0 mengekspos Milvus sebagai Spark DataSource V2, sehingga pekerjaan Spark, Databricks, dan EMR dapat membaca dari dan menulis ke Milvus sebagai bagian dari pipeline batch standar.

Fitur ini penting karena alur kerja data AI bersifat iteratif: deduplikasi memberi masukan ke re-embedding, clustering memberi masukan ke evaluasi, dan evaluasi menghasilkan set pelatihan atau serving yang telah dikurasi. Snapshot yang stabil menyediakan input konsisten bagi pekerjaan tersebut, sementara koleksi live tetap melayani. Dengan Spark connector, sink dari satu pekerjaan menjadi sumber untuk pekerjaan berikutnya, tanpa mengekspor seluruh koleksi keluar dari Milvus setiap kali.

Milvus 3.0 juga memperkenalkan operator batch vector-native untuk tugas seperti deduplikasi, deteksi anomali, dan clustering, menjaga pekerjaan yang berat komputasi tetap berada di luar jalur query online sambil beroperasi langsung pada data vektor.

5. Perubahan skema online dan backfill

Skema jarang tetap statis dalam produksi — seiring waktu, tim menambahkan model embedding baru, vektor sparse, label, field metadata, dan kebijakan retensi. Milvus 3.0 memungkinkan mereka menambah, mengisi, dan menghapus kolom sementara serving terus berjalan, bukan rebuild yang mengganggu seperti yang sebelumnya diperlukan.

Menambah atau menghapus kolom tidak memerlukan penulisan ulang data yang ada. client.add_collection_field(...) menempatkan kolom nullable baru tanpa membuat koleksi offline, dan client.drop_collection_field(...) menghapus field yang sudah deprecated atau eksperimental saat runtime. Keduanya tidak menulis ulang data yang ada — masing-masing adalah perubahan pada manifest koleksi, bukan pada file data, itulah sebabnya tidak ada rebuild.

Milvus 3.0 mendukung dua jalur backfill:

• Inner backfill (di 3.0) ditujukan untuk nilai yang diturunkan dari field yang ada. Milvus dapat menghasilkan vektor sparse BM25 dari kolom teks di dalam kernel, sehingga menghilangkan kebutuhan akan encoder sisi klien saat membangun retrieval hybrid dense-plus-sparse.
• External backfill(dalam roadmap) akan ditujukan untuk nilai yang dihitung di luar Milvus: ambil snapshot, jalankan Spark terhadap tampilan yang konsisten, hitung kolom baru, tulis kembali nilainya, dan biarkan Milvus memperbarui indeks secara inkremental. Ini adalah jalur yang dimaksudkan untuk pekerjaan re-embedding besar — misalnya, menambahkan kolom embedding baru di ratusan juta baris sementara penulisan terus berjalan.

Bersama-sama, perubahan skema online dan backfill memudahkan evolusi pipeline retrieval tanpa membangun ulang seluruh koleksi setiap kali model data berubah.

Engine yang Lebih Kuat untuk Retrieval End-to-End

Milvus telah lama mendukung lebih dari pencarian ANN dense, termasuk retrieval sparse berbasis BM25 dan pencarian hybrid. Milvus 3.0 memperluas engine pada sumbu yang berbeda: rilis ini membawa lebih banyak pipeline retrieval multi-tahap ke dalam Milvus itu sendiri, mengurangi over-fetching, logika aplikasi duplikatif, dan ketergantungan pada layanan post-processing terpisah.

1. ORDER BY sisi server: mengurutkan di dalam engine, per segmen

Sebelumnya, pengurutan mengharuskan aplikasi melakukan over-fetch kandidat, memindahkannya ke klien, dan mengurutkannya di sana. Itu mengonsumsi bandwidth dan membuat hasil akhir bergantung pada tempat pemotongan sisi klien terjadi.

Milvus 3.0 menambahkan ORDER BY sisi server, yang memungkinkan workload query mengurutkan baris yang telah difilter berdasarkan field skalar seperti rating, harga, freshness, inventaris, atau timestamp.

• Pada jalur query, setiap segmen mengurutkan set hasil yang telah difilter, node query menggabungkan stream tersebut, dan proxy mengembalikan slice yang diminta.
• Pada jalur pencarian, ORDER BY mengurutkan set kandidat ANN di dalam Milvus, mengurangi over-fetching sisi klien dan post-processing duplikatif. Ini tidak mengubah batas recall yang ditetapkan oleh kandidat ANN.

client.query(
    collection_name="products",
    filter="category == 'shoes'",
    output_fields=["price", "rating"],
    limit=10,
    order_by=["rating:desc", "price:asc"],
)

Ini sangat berguna untuk pencarian yang menggabungkan relevansi dengan batasan bisnis atau yang berhadapan dengan pengguna seperti rating, harga, freshness, inventaris, atau timestamp.

Untuk informasi selengkapnya, lihat Sort Search Results by Scalar Fields dan Sort Query Results.

2. Agregasi dan pencarian berfaset

Milvus 3.0 menambahkan agregasi sisi query dengan operasi seperti count, sum, average, minimum, dan maximum, yang dikelompokkan berdasarkan satu atau lebih field skalar. Ini menghilangkan pola umum ketika tim menarik baris yang telah difilter ke kode klien hanya untuk menghitung, mengelompokkan, atau menghitung statistik sederhana.

client.query(
    collection_name="orders",
    filter="in_stock == true",
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)", "max(rating)"],
)

Milvus 3.0 juga menambahkan agregasi pencarian untuk pencarian berfaset. Setelah pencarian ANN, Milvus mengelompokkan hit yang diambil berdasarkan sebuah field dan mengembalikan jumlah bucket, statistik agregat, serta hit sampel top-N per bucket — pola di balik pengelompokan berdasarkan merek, rentang harga, warna, tenant, atau jenis dokumen. Satu catatan: agregasi pencarian beroperasi atas set hasil yang diambil ANN, bukan seluruh koleksi, sehingga jumlah faset bersifat perkiraan. Ketika Anda membutuhkan jumlah yang tepat, gunakan agregasi sisi query.

Untuk informasi selengkapnya, lihat Aggregate Query Results.

3. StructArray untuk Vektor Bertingkat dan Model Late-Interaction

Banyak entitas secara alami direpresentasikan oleh beberapa vektor. Dokumen panjang adalah rangkaian chunk; video adalah urutan frame yang lebih baik Anda simpan bersama dalam satu baris daripada disebar ke banyak baris; produk memiliki beberapa gambar atau sudut. Model late-interaction mendorong ini lebih jauh — ColBERT menghasilkan satu vektor per token, ColPali satu per patch visual. Dalam setiap kasus, unit yang sebenarnya ingin Anda simpan dan cari adalah seluruh entitas, bukan setiap fragmen secara terpisah.

StructArray memungkinkan satu baris Milvus berisi array elemen terstruktur dengan panjang variabel, termasuk beberapa vektor, sambil mempertahankan satu ID entitas dan satu set metadata. Ini menghindari pemecahan dokumen menjadi beberapa baris dan duplikasi label, izin, atau field lain di berbagai fragmen.

Milvus mendukung dua granularitas pencarian.

• Pencarian tingkat elemen mencocokkan satu vektor query dengan setiap elemen dalam daftar dan mengembalikan elemen spesifik yang cocok beserta offset-nya. Ini berguna ketika Anda ingin mengetahui chunk, token, patch, atau gambar mana yang cocok. Satu baris dapat muncul lebih dari sekali jika beberapa elemen cocok.
• Pencarian tingkat entitas membandingkan daftar vektor lengkap milik query dengan daftar vektor milik baris menggunakan MAX_SIM, dengan metrik MAX_SIM_COSINE. Setiap token query mengambil kecocokan terbaiknya dalam dokumen, dan skor terbaik tersebut dijumlahkan. Ini memberi Milvus dukungan native untuk pola retrieval late-interaction seperti ColBERT dan ColPali sambil mempertahankan satu baris per dokumen.

Mengindeks setiap vektor token bisa mahal; jadi Milvus 3.0 menambahkan beberapa jalur akselerasi, termasuk TokenANN, Muvera, dan Lemur, yang menukar ukuran indeks, biaya pelatihan, dan recall.

Strategi	Representasi tahap pertama	Profil biaya	Paling cocok untuk
TokenANN	Setiap vektor token diindeks.	Tertinggi, exact	Model berdaya diskriminasi tinggi dan dokumen pendek
Muvera	Satu vektor per dokumen menggunakan FDE proyeksi acak.	Sedang, tanpa pelatihan	Dokumen panjang
Lemur	Satu vektor per dokumen menggunakan kompresi MLP terlatih	Terendah, memerlukan pelatihan	Model berdaya diskriminasi rendah dan vektor visual atau patch

Dalam benchmark kami, Lemur menyamai atau mengalahkan recall TokenANN pada sebagian besar dataset sambil meruntuhkan setiap dokumen menjadi satu vektor; pengecualiannya adalah korpus dengan variansi panjang yang tinggi, ketika TokenANN atau strategi lain lebih aman.

Untuk korpus yang lebih besar daripada memori, Milvus juga mendukung indeks DISKANN yang menyimpan daftar embedding di disk untuk mengurangi tekanan RAM.

Pencarian tingkat elemen sudah hadir di Milvus 2.6. Filtering untuk Muvera, Lemur, dan StructList baru di 3.0.

4. Kompresi Indeks BM25 dan SINDI

Milvus telah mendukung pencarian vektor sparse pada rilis sebelumnya. Milvus 3.0 mengurangi footprint indeks sparse melalui postings terkompresi blok (algoritma terkait VByte plus decoding SIMD) dan kuantisasi (fp16 untuk inner product, u16 untuk BM25).

Di salah satu rangkaian benchmark BM25 internal, implementasi baru kira-kira 3 kali lebih kecil daripada indeks sparse Milvus 2.6 pada recall yang sebanding. Indeks yang lebih kecil mengurangi tekanan memori dan bandwidth serta dapat meningkatkan kecepatan pada workload yang dibatasi oleh perpindahan data.

Milvus 3.0 juga memperkenalkan SINDI, algoritma retrieval sparse baru yang dioptimalkan untuk learned sparse embeddings seperti SPLADE. Karena embedding ini menghasilkan daftar posting yang lebih padat daripada BM25, algoritma pencarian yang banyak melakukan pruning dapat menghabiskan waktu CPU yang substansial untuk memutuskan apa yang harus dilewati. Sebaliknya, SINDI mengatur posting ke dalam jendela ringkas dan menggunakan akumulasi skor yang ramah SIMD untuk memprosesnya secara efisien, sambil mempertahankan akurasi retrieval melalui pruning lossless.

Kami juga memperluas SINDI melampaui desain aslinya untuk menyertakan dukungan BM25 native, sehingga Milvus dapat menggunakan jalur retrieval sparse yang sama-sama dioptimalkan untuk learned sparse embeddings dan pencarian full-text tradisional.

Dalam benchmark kami di 4 dataset vektor sparse SPLADE, SINDI mencapai hingga sekitar 10x QPS MaxScore pada vektor learned-sparse, dengan skenario terburuk sekitar 5x.

SINDI adalah default untuk pencarian inner-product sparse di Milvus 3.0.

Peningkatan Lainnya

• TEXT LOB: Menyimpan teks sumber panjang di samping vektor. Teks di bawah 64 KB tetap inline; nilai yang lebih besar menggunakan referensi Vortex LOB.
• Dukungan indeks dense yang diperluas: Menambahkan lebih banyak pilihan indeks dalam keluarga Faiss, termasuk SVS, Panorama, PQ, IVFPQ, dan ScaNN, untuk berbagai kebutuhan skala, memori, dan recall.
• MinHash dan pencarian near-duplicate: Menghasilkan signature MinHash di sisi server dan mengambil kandidat near-duplicate menggunakan MINHASH_LSH.
• Vektor nullable dan tipe baru: Memungkinkan field vektor bernilai NULL dan menambahkan TIMESTAMPTZ untuk filtering yang sadar waktu dan kebijakan retensi.
• Kamus full-text kustom: Mendaftarkan kamus, sinonim, dan resource stop-word pada cluster untuk tokenisasi multibahasa dan spesifik domain.
• Standalone Woodpecker: Menjalankan write-ahead log Milvus sebagai layanan yang dapat diskalakan dan diobservasi secara independen.
• Entity TTL****: Menghapus masa berlaku record individual melalui field TIMESTAMPTZ, dengan filtering MVCC diikuti garbage collection selama kompaksi.
• ForceMerge: Memadatkan segmen kecil ke ukuran target dan membangun ulang indeks untuk mengurangi amplifikasi baca sebelum layanan read-heavy berkelanjutan.
• Dan lainnya

Mulai menggunakan Milvus 3.0

Milvus 3.0 tersedia hari ini di bawah lisensi Apache 2.0 dan tetap menjadi proyek LF AI & Data. Untuk memulai:

• Baca release notes dan quickstart, dan dapatkan source di github.com/milvus-io/milvus.
• Bergabunglah dengan komunitas Milvus Discord atau pesan sesi Milvus Office Hours untuk mendiskusikan use case Anda dengan para maintainer.

Milvus 3.0 dan Zilliz Vector Lakebase

Milvus 3.0 meletakkan fondasi sumber terbuka untuk retrieval AI produksi dan arsitektur Vector Lakebase yang sedang berkembang, yang menggabungkan penyimpanan lake-native dengan retrieval vektor berkinerja tinggi pada satu sumber kebenaran, masing-masing pada biaya yang tepat.

Zilliz Cloud adalah Vector Lakebase terkelola penuh yang dibangun oleh tim di balik Milvus. Ini berbagi arsitektur terdistribusi lake-native yang sama dengan Milvus dan sepenuhnya kompatibel dengan API Milvus. Didukung oleh engine pengindeksan proprietary Cardinal, Zilliz Cloud memberikan price-performance hingga 10× lebih baik daripada pendekatan pengindeksan sumber terbuka standar sekaligus menghilangkan kompleksitas operasional dalam mengelola infrastruktur. Kapabilitas enterprise mencakup komputasi scale-to-zero, pemulihan bencana lintas region, deployment BYOC, keamanan dan kepatuhan tingkat enterprise (SOC 2, HIPAA, ISO 27001, dan GDPR), serta SLA hingga 99,99%.

Developer dapat men-deploy Milvus sebagai database vektor sumber terbuka atau menggunakan Zilliz Cloud untuk platform terkelola di berbagai workload sepanjang siklus hidup data AI.

Apa berikutnya

Roadmap Milvus dibangun di atas arsitektur 3.0 dengan predicate pushdown untuk External Collections, external backfill, operator Spark tambahan, dan dukungan untuk lebih banyak format tabel, termasuk Delta Lake dan Apache Paimon.

Arah yang lebih besar sudah jelas: sistem data AI membutuhkan loop yang lebih erat antara retrieval online dan peningkatan data offline. Data vektor tidak seharusnya harus disalin ke sistem terpisah setiap kali tim ingin mencari, menganalisis, meningkatkan, atau menyajikannya.