Zilliz

📣📣 𝗭𝗶𝗹𝗹𝗶𝘇 𝗖𝗹𝗼𝘂𝗱 𝗶𝘀 𝗻𝗼𝘄 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗪𝗦 𝗟𝗼𝗻𝗱𝗼𝗻 𝗿𝗲𝗴𝗶𝗼𝗻 (𝗲𝘂-𝘄𝗲𝘀𝘁-𝟮)! As AI applications reach more users across the UK, organizations need infrastructure that can deliver low latency, support local data residency, and control costs. What this means to you: 🌍 𝗟𝗼𝘄𝗲𝗿 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 - Run vector search closer to UK users for faster, more consistent responses. 🔒 𝗨𝗞 𝗱𝗮𝘁𝗮 𝗿𝗲𝘀𝗶𝗱𝗲𝗻𝗰𝘆 - Keep vector data in the UK to support residency and compliance requirements. 💰 𝗟𝗼𝘄𝗲𝗿 𝗱𝗮𝘁𝗮 𝘁𝗿𝗮𝗻𝘀𝗳𝗲𝗿 𝗰𝗼𝘀𝘁𝘀 - Co-locate your vector database with UK-based applications to reduce cross-region traffic and related transfer costs. ⚡ 𝗦𝘁𝗿𝗼𝗻𝗴𝗲𝗿 𝗔𝗜 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 - Support more responsive RAG, search, chat, and recommendation systems. Zilliz Cloud now spans 𝟮𝟯 𝗿𝗲𝗴𝗶𝗼𝗻𝘀 across AWS, Google Cloud, and Microsoft Azure, giving teams more flexibility to deploy closer to their users, data, and applications. 👉 See all available regions: https://lnkd.in/eABfbWHQ

📢 𝗪𝗲𝗯𝗶𝗻𝗮𝗿 𝗿𝗲𝗺𝗶𝗻𝗱𝗲𝗿 | 𝗙𝗮𝘀𝘁𝗲𝗿 𝗮𝗻𝗱 𝗠𝗼𝗿𝗲 𝗣𝗼𝘄𝗲𝗿𝗳𝘂𝗹 𝗙𝘂𝗹𝗹-𝗧𝗲𝘅𝘁 𝗦𝗲𝗮𝗿𝗰𝗵 𝘄𝗶𝘁𝗵 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬, happening this Wednesday If you’re building semantic, lexical, or hybrid search with Milvus, or comparing it with Elasticsearch for production retrieval, this webinar is for you. Simon Hearne, Solutions Architect at Zilliz, will walk through Milvus 3.0’s full-text search capabilities, live side-by-side queries, and what matters when choosing your retrieval stack. Can’t join live? Register now and we’ll send you the recording and demo after the session. 📅 𝗪𝗲𝗱𝗻𝗲𝘀𝗱𝗮𝘆, 𝗔𝘂𝗴𝘂𝘀𝘁 𝟭𝟵, 𝟮𝟬𝟮𝟲 🌐 𝟭𝟭:𝟬𝟬 𝗔𝗠 𝗣𝗗𝗧 🔗 𝗥𝗲𝗴𝗶𝘀𝘁𝗲𝗿 𝗵𝗲𝗿𝗲: https://lnkd.in/gTH2Z6kF

🔥 Webinar invitation: 𝗙𝗮𝘀𝘁𝗲𝗿 𝗮𝗻𝗱 𝗠𝗼𝗿𝗲 𝗣𝗼𝘄𝗲𝗿𝗳𝘂𝗹 𝗙𝘂𝗹𝗹-𝗧𝗲𝘅𝘁 𝗦𝗲𝗮𝗿𝗰𝗵 𝘄𝗶𝘁𝗵 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬 Milvus is known for vector search. With Milvus 3.0, full-text search gets a major upgrade, giving teams more options for building semantic, lexical and hybrid search with one retrieval engine. Join Simon Hearne, Solutions Architect at Zilliz, for a technical deep dive into 𝗠𝗶𝗹𝘃𝘂𝘀 𝟯.𝟬’s full-text search capabilities. He’ll compare Milvus with Elasticsearch, walk through live side-by-side queries, and discuss how full-text and vector search can work together for hybrid retrieval. 📅 𝗔𝘂𝗴𝘂𝘀𝘁 𝟭𝟵, 𝟮𝟬𝟮𝟲 | 𝟭𝟭:𝟬𝟬 𝗔𝗠 𝗣𝗗𝗧 🔗 𝗥𝗲𝗴𝗶𝘀𝘁𝗲𝗿 𝗵𝗲𝗿𝗲: https://lnkd.in/gTH2Z6kF 🎤 𝗪𝗵𝗮𝘁 𝘁𝗼 𝗲𝘅𝗽𝗲𝗰𝘁: • BM25 and sparse retrieval in Milvus 3.0 • Filtering, sorting, aggregation, and faceted search • Elasticsearch vs. Milvus capabilities and tradeoffs • Live side-by-side queries with results and latency on screen • Hybrid search and ranking with methods such as RRF • Production examples and more  Bring your search patterns and architecture questions, and join us live. 👉 Follow Zilliz for vector database and vector lakebase updates built for production AI. #Milvus #FullTextSearch #VectorDatabase

𝗛𝗼𝘄 𝗱𝗼 𝘆𝗼𝘂 𝗸𝗲𝗲𝗽 𝘆𝗼𝘂𝗿 𝗱𝗮𝘁𝗮 𝗶𝗻𝘀𝗶𝗱𝗲 𝘆𝗼𝘂𝗿 𝗩𝗣𝗖—𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗴𝗶𝘃𝗶𝗻𝗴 𝘂𝗽 𝗮 𝗳𝘂𝗹𝗹𝘆 𝗺𝗮𝗻𝗮𝗴𝗲𝗱 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲? With 𝗭𝗶𝗹𝗹𝗶𝘇 𝗖𝗹𝗼𝘂𝗱 𝗕𝗬𝗢𝗖, vector database workloads, monitoring infrastructure, and persistent storage stay inside your own cloud account and VPC. The Zilliz control plane communicates with the data plane through a secure outbound connection over port 443—without requiring inbound traffic from the control plane. This means your organization retains control over its data and infrastructure, while Zilliz continues to manage: • Software upgrades • Scaling and auto-scaling policies • Monitoring dashboards and metrics • Alerts and day-two operations  In this clip, Jiang Chen, Head of Developer Relations and Solutions at Zilliz, explains how Zilliz BYOC combines 𝗱𝗮𝘁𝗮 𝘀𝗼𝘃𝗲𝗿𝗲𝗶𝗴𝗻𝘁𝘆 with the same managed experience teams expect from Zilliz Cloud. ▶ Watch the full 𝗭𝗶𝗹𝗹𝗶𝘇 𝗕𝗬𝗢𝗖 (𝗕𝗿𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗢𝘄𝗻 𝗖𝗹𝗼𝘂𝗱) webinar replay: https://lnkd.in/gvVYQh55 👉 Follow Zilliz for more on vector databases and enterprise AI infrastructure built for production. #ZillizCloud #BYOC #VectorDatabase #DataSovereignty #CloudInfrastructure #Milvus

🇯🇵 𝗭𝗶𝗹𝗹𝗶𝘇 𝗛𝗮𝗻𝗱𝘀-𝗼𝗻 | 日本語ベクトル検索 | September 17, Tokyo If you want to improve your RAG performance, scale vector search to meet production requirements, combine it with Elasticsearch or OpenSearch, or get more from an existing Milvus deployment, join us for Zilliz’s first workshop in Japan. In this hands-on session, you’ll build Japanese search on Zilliz Cloud with Milvus 2.6, combining Japanese tokenization, BM25, dense vectors, hybrid search, and multimodal retrieval. We’ll also demo a self-hosted Milvus-to-Zilliz Cloud migration and Milvus 3.0 External Collections. The workshop will be led by: Yulan Yan (顔 玉蘭), Founding Solution Architect at Zilliz, PhD, ex-Databricks / ex-IBM 𝗪𝗵𝗮𝘁 𝘆𝗼𝘂’𝗹𝗹 𝗯𝘂𝗶𝗹𝗱 • Japanese semantic search • BM25 and dense hybrid search with reranking • Japanese text-to-image retrieval • Production-scale search patterns 📅 Thursday, September 17, 2026, 18:30–21:20 📍 𝗧𝗞𝗣 𝗧𝗼𝗸𝘆𝗼 𝗦𝘁𝗮𝘁𝗶𝗼𝗻 𝗖𝗼𝗻𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗖𝗲𝗻𝘁𝗲𝗿, 𝗖𝗼𝗻𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗥𝗼𝗼𝗺 𝟭𝗔 No preparation is required. Bring a laptop with a browser, and we’ll set everything up together. Limited to 50 participants. ➡️ Regesiter Here: https://lnkd.in/gVrR9-yT #Milvus #Zilliz #VectorSearch

𝗪𝗵𝘆 𝗥𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁𝘀 𝗡𝗲𝗲𝗱 𝗠𝗼𝗿𝗲 𝗧𝗵𝗮𝗻 𝗮 𝗦𝗺𝗮𝗿𝘁𝗲𝗿 𝗠𝗼𝗱𝗲𝗹 For long-running agent systems, model intelligence is only part of the challenge. The harder problem is preserving reliable progress across sessions, tools, approvals, and changing external conditions. A common design keeps one agent in a loop: decide the next step, execute it, evaluate the result, and continue. But when goals and evidence live only in the model context, progress can disappear between sessions. When the same agent both executes and evaluates, weak results may pass. And one unresolved approval can block the entire workflow. The answer is not to replace loops with graphs. A loop controls how one unit of work keeps iterating. A graph makes coordination explicit—how work branches, runs in parallel, waits, and resumes. Reliable systems combine the two: durable state preserves continuity, while an Explore–Execute–Judge graph separates planning, execution, and validation. Human review can follow the same principle. Instead of freezing the entire workflow, only the branch waiting for approval pauses while independent work continues. But orchestration alone is not enough. Each node also needs the right context when it makes a decision. 𝗠𝗲𝗺𝗦𝗲𝗮𝗿𝗰𝗵 retrieves relevant project history, decisions, and preferences across agents. 𝗠𝗙𝗦 complements that history with current information distributed across repositories, documents, databases, and SaaS tools. These patterns come together in the open-source 𝗣𝗲𝗿𝗽𝗲𝘁𝘂𝘂𝗺 skill project. 𝗧𝗵𝗲 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆: 𝗮𝘀 𝗮𝗴𝗲𝗻𝘁 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀 𝗴𝗿𝗼𝘄 𝗹𝗼𝗻𝗴𝗲𝗿, 𝗿𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻𝗰𝗿𝗲𝗮𝘀𝗶𝗻𝗴𝗹𝘆 𝗹𝗶𝘃𝗲𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗵𝗮𝗿𝗻𝗲𝘀𝘀 𝗮𝗿𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹, 𝗻𝗼𝘁 𝗶𝗻 𝗺𝗼𝗱𝗲𝗹 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝗰𝗲 𝗮𝗹𝗼𝗻𝗲.

🚀 See how to deploy Zilliz Cloud BYOC-I on Google Cloud—while keeping your data plane and vector data inside your own GCP VPC. For financial services, healthcare, public sector teams, and other highly regulated organizations, production AI often comes with strict requirements for data residency, infrastructure ownership, security, and access control. Zilliz Cloud BYOC-I is designed for these environments. It separates the control plane from the data plane: Zilliz operates the control plane, where no customer data is stored, while your Kubernetes clusters, vector database clusters, and object storage remain in your cloud. This four-minute walkthrough shows the deployment workflow: ✅ Create a BYOC-I project and data plane in Zilliz Cloud ✅ Select a GCP region and configure resource and autoscaling settings ✅ Prepare the data plane and deploy the required resources with Terraform ✅ Monitor the deployment as it moves from Deploying to Running ✅ See how outbound monitoring works and how you control technical support access If security, compliance, and cloud ownership are critical to your production AI workloads, watch the demo to see Zilliz Cloud BYOC-I in action. 🎥 Watch the walkthrough: https://lnkd.in/gW8MTCRc 📄 Deployment docs: https://lnkd.in/gpQThkZb 💬 Talk to sales: https://lnkd.in/gKTw54p2 👉 Explore Zilliz Cloud BYOC: https://lnkd.in/gkh6E_ej #VectorDatabase #GoogleCloud #AIInfrastructure #DataSecurity #BYOC

𝗪𝗵𝘆 𝗜𝗩𝗙 𝗢𝗳𝘁𝗲𝗻 𝗙𝗶𝘁𝘀 𝗟𝗮𝗿𝗴𝗲 𝗧𝗼𝗽-𝗞 𝗦𝗲𝗮𝗿𝗰𝗵 𝗕𝗲𝘁𝘁𝗲𝗿 𝗧𝗵𝗮𝗻 𝗛𝗡𝗦𝗪 HNSW is often a strong choice when you need a small set of nearest neighbors. But as top-k grows into the tens of thousands, its advantages can start to erode. This matters in workloads such as autonomous-driving corner-case mining and targeted dataset retrieval for model training, where a single query may need to return a very large result set. 𝗙𝗼𝗿 𝗛𝗡𝗦𝗪, 𝗹𝗮𝗿𝗴𝗲 𝘁𝗼𝗽-𝗸 𝗰𝗿𝗲𝗮𝘁𝗲𝘀 𝗽𝗿𝗲𝘀𝘀𝘂𝗿𝗲 𝗶𝗻 𝘁𝗵𝗿𝗲𝗲 𝗽𝗹𝗮𝗰𝗲𝘀. First, the search has to expand across more of the graph. The small number of jumps that makes HNSW efficient for smaller k is no longer enough, so the system visits many more nodes. Second, every visited node can trigger distance computation and candidate-queue updates. With tens of thousands of results, the queue consumes more memory and requires many insertions, removals, and heap adjustments. Third, graph traversal amplifies random memory access. Nodes and adjacency lists are often spread across memory, so wider searches lead to more cache misses and can become constrained by memory latency or bandwidth. For these workloads, an IVF-based index is often a better fit. IVF stores vectors in clustered inverted lists, enabling more sequential reads and better memory locality. Its layout also maps well to batch computation using CPU SIMD and AVX-512 instructions, or large-scale parallel processing on GPUs. Just as importantly, IVF separates routing from scanning: it first selects relevant clusters, then scans the chosen lists in batches. When k is large and scanning dominates the workload, that structure can deliver more stable throughput. 𝗧𝗵𝗲 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆: 𝗶𝗻𝗱𝗲𝘅 𝗰𝗵𝗼𝗶𝗰𝗲 𝘀𝗵𝗼𝘂𝗹𝗱 𝗿𝗲𝗳𝗹𝗲𝗰𝘁 𝗿𝗲𝘀𝘂𝗹𝘁-𝘀𝗲𝘁 𝘀𝗶𝘇𝗲, 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝗱𝗮𝘁𝗮𝘀𝗲𝘁 𝘀𝗶𝘇𝗲.

𝗛𝗼𝘄 𝘁𝗼 𝗥𝗲𝗱𝘂𝗰𝗲 𝗖𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲-𝗦𝗲𝘁 𝗢𝘃𝗲𝗿𝗵𝗲𝗮𝗱 𝗶𝗻 𝟭𝟬𝗞+ 𝗧𝗼𝗽-𝗞 𝗦𝗲𝗮𝗿𝗰𝗵 For large top-k search, distance computation is only part of the cost. Maintaining tens of thousands of candidates can become a bottleneck of its own. In autonomous-driving corner-case mining and targeted dataset retrieval for model training, a single query may need tens of thousands of similar results. The conventional approach keeps a priority queue of size k. For each new candidate, the system may need to insert it, compare it with the current worst result, remove that result, and rebalance the heap. When k is large, this sequence can run millions of times. Memory usage grows with the queue, while fine-grained heap operations continue consuming CPU. But large top-k search does not require a perfectly ordered candidate set throughout the scan. It only needs the correct best k from the candidates examined when the scan finishes. 𝗭𝗶𝗹𝗹𝗶𝘇 𝗖𝗹𝗼𝘂𝗱 uses a reservoir-based candidate buffer to take advantage of that distinction. The reservoir is larger than k. During the search, candidates that pass the current threshold are appended directly, without rebalancing a heap after every insertion. Only when the reservoir reaches capacity does the system run a batch selection, retain the best k candidates, and update the threshold. This converts a large number of small insert, remove, and rebalance operations into fewer bulk selection passes. 𝗔𝘀 𝗸 𝗶𝗻𝗰𝗿𝗲𝗮𝘀𝗲𝘀, 𝘁𝗵𝗲 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗶𝗻 𝗰𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲-𝗺𝗮𝗶𝗻𝘁𝗲𝗻𝗮𝗻𝗰𝗲 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝗶𝗻𝗰𝗿𝗲𝗮𝘀𝗶𝗻𝗴𝗹𝘆 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲.

𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗶𝗻𝗴 𝗟𝗮𝗿𝗴𝗲 𝗧𝗼𝗽-𝗞 𝗩𝗲𝗰𝘁𝗼𝗿 𝗦𝗲𝗮𝗿𝗰𝗵 𝗳𝗼𝗿 𝗖𝗼𝘀𝘁-𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗗𝗮𝘁𝗮 𝗠𝗶𝗻𝗶𝗻𝗴 Large top-k vector search gets expensive for a reason that is easy to miss: every segment is often given the same search budget, even though not every segment contributes equally to the final result. In a distributed vector database, a query is fanned out across multiple QueryNodes. Each QueryNode searches its assigned segments, returns a local top-k candidate set, and the system merges those candidates into the final top-k. For small k, the redundant work is usually manageable. For large top-k workloads, such as model training or autonomous vehicle data mining, it becomes a major cost driver. If every segment runs the same full large top-k search, the system spends compute on low-contribution segments, moves more intermediate results across the network, and increases the cost of global merging. Zilliz Cloud 𝗔𝘂𝘁𝗼𝗜𝗻𝗱𝗲𝘅 takes a more adaptive approach. Using machine learning and runtime statistics, AutoIndex estimates how much each segment is likely to contribute to the final result, then assigns search budgets accordingly. High-contribution segments can search more broadly and return more candidates. Low-contribution segments can search less and return fewer results. The system no longer requires every segment to produce the same local top-k. While maintaining the target recall, this can reduce: • Index search work within each segment • Intermediate results returned by QueryNodes • Data transferred between nodes • Compute required for global result merging How are you handling large top-k workloads in your retrieval stack?