AI/ML
Zilliz has produced a Milvus Vector Lakebase FAQ to help position its vector database and vector lakebase offerings in your mental landscape. We reproduce it here.
Is Zilliz moving away from vector databases?
No. Real-time vector search stays the core serving engine – it just now lives inside a bigger system, the way OLTP databases stayed essential inside the lakehouse. Milvus remains an open-source vector database, and Zilliz Cloud's production vector search keeps getting faster and cheaper. More details here.
What does "lake-native" mean (vs. cloud-native)? Cloud-native describes software built to run elastically on cloud infrastructure. Lake-native means the data's primary home is open formats on cloud object storage (a data lake) – not loaded into a separate database as the source of truth. Data persists in the lake; compute attaches to it on demand. Vector Lakebase is both.
What is "unified lake-native storage"?
One storage layer, on object storage, that serves both low-latency online search and large-scale analytics over the same files – so you don't keep one copy for serving and another for processing. Zilliz built it on its Loon storage engine and the open Vortex format. More details here.
Is Vector Lakebase available for self-hosted Milvus?
Real-time vector search is available in open-source Milvus, which you can self-host. The Vector Lakebase capabilities – on-demand compute, external data lake search, and tiered serving – are delivered as part of the managed Zilliz Cloud platform. More details here.
Do discovery and batch workloads slow down real-time serving?
No. Each compute mode runs on its own elastic compute against the shared data: production serving uses resident, preloaded clusters, while discovery and batch run on separate on-demand or offline compute. Improvements flow back to serving atomically as a new snapshot, so serving never reads half-built data.
External Data Lake Search – does it copy my data?
No. External Collection creates a zero-copy logical mapping to your existing Lance, Iceberg, Parquet, or Vortex tables and builds the search indexes on top. Your data stays in your lake under your governance; updates are picked up via incremental sync (a refresh call), not a continuous change stream.
Who generates the vectors, and where do they live?
Your source data stays in your lake and is converted into vector embeddings using embedding models. Zilliz builds and manages the index layer (vector, full-text, JSON) that makes it searchable, rather than taking a second copy.