Zilliz/Milvus EU Alternative 2026: The Dual Jurisdiction Paradox — CLOUD Act Meets China NSL

Post #4 in the sota.io EU Vector Database Tools Series

Every vector database in this series so far has had one jurisdiction problem. Pinecone: Delaware C-Corp, pure CLOUD Act exposure. Weaviate: Dutch BV with US venture capital complicating the sovereign story. Chroma: Delaware C-Corp with a telemetry trap baked into the default configuration.

Zilliz is different. Zilliz is the first vector database in this series with a dual jurisdiction problem.

On one side: Zilliz Corp is incorporated as a Delaware C-Corp with headquarters in Menlo Park, California. That's a standard US CLOUD Act nexus—law enforcement can serve a valid order and compel disclosure of customer data.

On the other side: Zilliz's primary engineering operations are based in Beijing and Shanghai, China. That creates exposure to China's National Intelligence Law (NIL, 2017), which requires all Chinese organizations and citizens to "support and cooperate" with state intelligence activities. For a company with core engineering in China, this is a meaningful secondary jurisdiction risk.

EU developers using Zilliz Cloud for their RAG pipelines are, in effect, operating under the surveillance potential of two separate national intelligence frameworks simultaneously.

Milvus, the Apache 2.0 open-source vector database that Zilliz created and primarily maintains, is the escape hatch—but only if you understand exactly how to use it.

What Is Zilliz? What Is Milvus?

These are two related but legally distinct entities:

Zilliz Corp:

• Entity: Zilliz Inc.
• Incorporation: Delaware C-Corp
• Headquarters: Menlo Park, California, USA
• Engineering operations: Beijing + Shanghai, China
• Investors: Hillhouse Capital, Yunqi Partners, 5Y Capital (all Asia-focused VCs), plus US investors
• Product: Zilliz Cloud — fully managed vector database service built on Milvus

Milvus:

• Type: Open-source vector database
• License: Apache 2.0
• Foundation: Linux Foundation AI & Data (LFAI)
• Created by: Zilliz Corp (2019)
• Primary maintainer: Zilliz Inc. (by commit volume and roadmap direction)
• Repository: github.com/milvus-io/milvus

The critical distinction: Milvus the software is Apache 2.0 and governed under the Linux Foundation umbrella. Zilliz Corp the company is a Delaware C-Corp with Chinese engineering operations. Using Milvus self-hosted is not the same as using Zilliz Cloud—but the two are more entangled than the Apache 2.0 license suggests.

CLOUD Act Exposure Matrix: Zilliz Cloud vs. Milvus Self-Hosted

D1: Corporate Jurisdiction — 5/5 for Cloud, 3-5/5 for Self-Hosted

For Zilliz Cloud, D1 is an unambiguous 5/5. Zilliz Corp is a Delaware C-Corp and a "covered provider" under the CLOUD Act. A valid US government order can compel disclosure of any data Zilliz controls, stores, or can access.

For Milvus self-hosted, D1 is more nuanced. The software is Apache 2.0 under the Linux Foundation, which reduces the direct vendor relationship. However, Zilliz Inc. remains the primary committer and de facto roadmap controller for the Milvus project. The LF AI governance provides some insulation—the project cannot be unilaterally weaponized by Zilliz for data collection—but Zilliz's Delaware incorporation still creates a D1 score of 3-5/5 depending on your deployment depth:

• If you pull container images from milvusdb/milvus on DockerHub (Zilliz-controlled): D1 = 5/5
• If you build from source or use a pinned, audited LF release: D1 = 3/5 (corporate stewardship risk, but reduced operational exposure)

D2: Infrastructure Location — 3/5 Managed, 0/5 Self-Hosted

Zilliz Cloud runs on AWS and Azure in US regions (with some international expansion). For EU customers, embedding vectors are transmitted to and stored in US-jurisdiction cloud infrastructure, giving a 3/5 (not 4/5 because Zilliz has begun offering AWS EU regions for enterprise tiers—but the default is US-east).

Self-hosted Milvus on EU infrastructure (Hetzner, OVHcloud, Scaleway) gets 0/5. Data never leaves your environment.

D3: Data Sensitivity — 5/5 Managed, 0/5 Self-Hosted

The RAG Pipeline Memory Paradox applies here too: embedding vectors derived from EU user interactions are personal data under GDPR Art.4(1) when they encode semantically identifiable content. For Zilliz Cloud, EU user query vectors stored in US jurisdiction create the same Art.44 transfer compliance problem as Pinecone or Chroma Cloud.

For self-hosted Milvus with EU data, D3 is 0/5—your embeddings, your infrastructure.

D4: Personnel & Operations — 4/5 (Unique in This Series)

This is the dimension where Zilliz stands apart from every other vector database in this series.

Zilliz's D4 is 4/5—higher than Pinecone (3/5), Weaviate (2/5), or Chroma (3/5)—because China's National Intelligence Law creates a secondary exposure channel that doesn't exist for purely US-incorporated companies.

China's National Intelligence Law (Guójiā qínggǎo fǎ, 2017), Article 7 states:

"All organizations and citizens shall support, assist, and cooperate with national intelligence work in accordance with the law."

For a company with primary engineering operations in China, this creates a theoretical pathway for Chinese state intelligence services to request cooperation from Chinese-based employees—independent of any US CLOUD Act process. The two exposure vectors operate in parallel:

• CLOUD Act route: US government → Zilliz Corp (Delaware) → production data
• China NSL route: Chinese state → Chinese engineers → potential access to systems or code

Whether the NSL route represents a realistic operational risk depends on your threat model. For EU enterprises handling sensitive data (financial, health, legal), both routes must be addressed in a DPIA.

No other vector database in this series has required EU DPO teams to address simultaneous US CLOUD Act exposure AND Chinese national security law exposure in the same risk assessment.

D5: Government Contracts — 1/5

No known US government contracts or FedRAMP certifications. 1/5 rather than 0/5 because the corporate structure creates potential for undisclosed future relationships.

The Dual Jurisdiction Paradox: A New Category of Sovereignty Risk

Previous posts in this series introduced three named risk patterns:

• RAG Pipeline Memory Paradox (Pinecone, Post #1): Embeddings of EU users' conversations stored permanently in US jurisdiction
• WCS Trap (Weaviate, Post #2): Start sovereign self-hosted, migrate to managed service, lose sovereignty
• Telemetry Trap (Chroma, Post #3): "Local-first" product defaults to US data transfer via anonymous telemetry

Zilliz introduces a fourth pattern: The Dual Jurisdiction Paradox.

A Dual Jurisdiction Paradox occurs when a single technology vendor is simultaneously subject to two distinct national intelligence frameworks with conflicting obligations. In Zilliz's case:

• The US CLOUD Act creates a disclosure obligation enforceable by US courts against Zilliz Corp
• China's National Intelligence Law creates a cooperation obligation enforceable by Chinese authorities against Zilliz's Chinese engineering operations

The paradox is legal, not just practical: if a US court orders Zilliz to preserve data pending disclosure review, while simultaneously Chinese authorities request access or modification, Zilliz could face conflicting legal obligations with no clear resolution path under either jurisdiction's law.

For EU data protection officers, this is a novel risk category that standard CLOUD Act risk assessments don't cover. GDPR Art.35 DPIA templates typically address a single third-country transfer. Zilliz requires a multi-jurisdiction analysis.

Milvus: The Open-Source Escape Hatch — How It Actually Works

Milvus is, by any measure, a technically excellent vector database. It was purpose-built for scale (billion-vector collections), cloud-native from the start (Kubernetes-native architecture), and has accumulated significant enterprise adoption globally. The LF AI & Data Foundation governance is genuine—the project has a Technical Steering Committee (TSC), a governance charter, and a release process that isn't solely controlled by Zilliz.

For EU developers, the question is: does Milvus self-hosted provide adequate sovereignty insulation from Zilliz's dual jurisdiction exposure?

The honest answer is: yes, but only if you deploy it correctly.

The Container Registry Trap

The most common Milvus deployment path uses Helm:

helm repo add milvus https://zilliz.github.io/milvus-helm/
helm install milvus milvus/milvus

The default Helm chart pulls container images from DockerHub under the milvusdb organization:

• milvusdb/milvus — primary database binary
• milvusdb/milvus-etcd — etcd for metadata
• milvusdb/milvus-minio — object storage (MinIO)

These images are built, signed, and distributed by Zilliz infrastructure. When your Kubernetes cluster pulls these images, it makes network calls to infrastructure that Zilliz controls.

Why this matters for D1 scoring: Even if your embedding data never touches Zilliz servers, your operational dependency on Zilliz-controlled container images creates a soft infrastructure relationship. A supply-chain intervention in the image pipeline could, in theory, introduce monitoring or data exfiltration at the software layer. This is not a hypothetical unique to Zilliz—it's the standard software supply chain risk—but the dual jurisdiction exposure elevates its severity.

Mitigation: Mirror the Milvus images to your own container registry (Harbor on EU infrastructure, or ECR/ACR in an EU region). Pull from Zilliz DockerHub once, push to your registry, pin to a specific image hash, and deploy from your registry. This severs the operational dependency on Zilliz infrastructure.

# Pull from DockerHub (one time, in a controlled environment)
docker pull milvusdb/milvus:v2.4.1
# Tag and push to your EU registry
docker tag milvusdb/milvus:v2.4.1 registry.eu.yourcompany.com/milvus:v2.4.1
docker push registry.eu.yourcompany.com/milvus:v2.4.1
# In Helm values.yaml, override image sources

Linux Foundation Governance: What It Provides (And What It Doesn't)

The LFAI membership is meaningful but limited:

What LF governance provides:

• A neutral foundation that cannot be unilaterally acquired by Zilliz
• An open governance charter that prevents stealth code changes without community visibility
• An independent Technical Steering Committee with non-Zilliz members
• Apache 2.0 licensing that allows forks without permission

What LF governance does NOT provide:

• Legal immunity from CLOUD Act orders to Zilliz Corp
• Insulation from China NSL obligations on Zilliz's Chinese engineers
• Guaranteed supply chain integrity of DockerHub images
• A warranty that future Zilliz employees won't introduce monitoring in contributions

The LF AI Foundation is itself a US 501(c)(6) nonprofit incorporated in San Francisco. The foundation is not subject to CLOUD Act as a "covered provider" for data it doesn't store—but it cannot override Zilliz Corp's own legal obligations.

Practical conclusion: LFAI membership reduces the corporate control risk (D1 from 5/5 to 3/5 for build-from-source deployments) but does not eliminate it. It's a governance safeguard, not a legal shield.

The Zilliz Cloud Managed Tier: Developer Convenience vs. Sovereignty

Zilliz Cloud offers a free tier with 2GB storage and multiple paid tiers, positioned as "Milvus without the ops overhead." The developer experience is polished—similar to Pinecone's managed offering in terms of API simplicity and scalability.

For EU developers, the managed tier creates the same sovereignty dead-end as every other US-hosted managed vector database:

Zilliz Cloud GDPR compliance requirements:

1. Art.28 DPA: Required for any EU personal data processing—verify this exists for your tier before ingesting PII-derived embeddings
2. Art.44 transfer basis: EU-US DPF coverage, SCCs, or adequacy decision required—the free tier's terms may not include adequate SCCs
3. Art.35 DPIA: Mandatory for high-risk processing given the dual jurisdiction exposure (US CLOUD Act + China NSL)
4. Art.30 RoPA: The transfer to Zilliz Cloud must be documented as an international transfer—often missed when developers treat Zilliz Cloud as just another cloud API

The free tier onboarding flow does not foreground these requirements. EU developers who start with the free tier for prototyping often continue to production without completing the GDPR compliance steps.

EU Alternatives: The Sovereignty Spectrum After Four Posts

Through four posts in this series, the EU vector database sovereignty spectrum is now clear:

Qdrant GmbH — The Sovereignty Baseline

Qdrant remains the reference sovereign vector database. Berlin-incorporated GmbH, no US parent, no US VC with board control, no PRC engineering operations. For EU teams that need Milvus-scale performance (billion vectors), Qdrant's Rust-native implementation offers comparable throughput.

For teams already invested in Milvus's API surface, the migration path to Qdrant is manageable—the conceptual model (collections, vectors, payloads) maps well between the two systems.

Vespa.ai — For Complex Hybrid Search

Vespa.ai (Norwegian AS) handles hybrid search requirements that neither Milvus nor Qdrant address as natively—combining dense vector search with BM25 keyword search and structured filtering in a single query execution plan. For EU teams building complex search architectures (e-commerce, document intelligence, semantic search with keyword fallback), Vespa is worth evaluating before defaulting to Qdrant.

pgvector — The Zero-Overhead Path

For applications already on PostgreSQL (Supabase, Neon, self-hosted Postgres on Hetzner), pgvector eliminates the need for a separate vector infrastructure vendor entirely. If your vector collection fits within Postgres's scaling envelope (hundreds of millions of moderate-dimension vectors with appropriate HNSW indexes), pgvector has zero CLOUD Act exposure, zero additional vendor relationships, and integrates with your existing backup and monitoring tooling.

Implementation: Running Milvus Sovereignly on EU Infrastructure

For EU teams committed to Milvus (perhaps due to existing API investment or billion-scale requirements), here is the sovereign deployment pattern:

Step 1: Mirror Container Images to Your EU Registry

# Required Milvus components
MILVUS_VERSION="v2.4.1"
REGISTRY="registry.eu.yourcompany.com"

images=(
  "milvusdb/milvus:${MILVUS_VERSION}"
  "milvusdb/milvus-etcd:3.5.5"
  "milvusdb/milvus-minio:RELEASE.2023-03-20T20-16-18Z"
)

for img in "${images[@]}"; do
  docker pull "$img"
  tag="${img#*/}"  # strip milvusdb/ prefix
  docker tag "$img" "${REGISTRY}/${tag}"
  docker push "${REGISTRY}/${tag}"
done

Step 2: Override Helm Chart Image Sources

# values-eu-sovereign.yaml
image:
  all:
    registry: registry.eu.yourcompany.com
    tag: v2.4.1

etcd:
  image:
    registry: registry.eu.yourcompany.com

minio:
  image:
    registry: registry.eu.yourcompany.com

Step 3: Deploy on EU Infrastructure

helm install milvus milvus/milvus \
  -f values-eu-sovereign.yaml \
  --namespace milvus-system \
  --create-namespace

This deployment pattern achieves:

• All data stored on your EU Kubernetes cluster
• No runtime dependency on Zilliz infrastructure (no DockerHub pulls after registry mirror)
• Apache 2.0 licensing with no operational vendor relationship
• CLOUD Act D1 score reduced to 3/25 (Zilliz corporate stewardship, no operational touchpoints)

Step 4: Update Your DPIA

Document the residual D1 risk in your GDPR Art.35 DPIA:

• Zilliz Inc. (Delaware) is the primary maintainer of the Milvus open-source software
• No operational data relationship with Zilliz—self-hosted on EU infrastructure
• Supply chain attestation: images sourced from LFAI-governed releases, mirrored to internal registry
• China NSL exposure: limited to Zilliz's corporate status as software author; no data processing relationship

This documentation typically satisfies DPO requirements for medium-risk use cases.

Migration: From Zilliz Cloud to Self-Hosted Milvus

For teams currently using Zilliz Cloud who need to improve sovereignty posture:

from pymilvus import connections, Collection, utility

# 1. Connect to Zilliz Cloud (export phase)
connections.connect(
    alias="zilliz",
    uri="https://your-cluster.zilliz.com",
    token="your_api_key"
)

# 2. Export collection schema and data
collection = Collection("your_collection", using="zilliz")
collection.load()

# Query in batches for export
results = collection.query(
    expr="pk >= 0",
    output_fields=["pk", "vector", "metadata"],
    limit=10000,
    offset=0
)

# 3. Connect to EU self-hosted Milvus
connections.connect(
    alias="eu_milvus",
    host="milvus.eu.yourinfra.com",
    port=19530
)

# 4. Recreate collection and ingest
from pymilvus import CollectionSchema, FieldSchema, DataType
schema = CollectionSchema(fields=[...])  # match original schema
Collection("your_collection", schema=schema, using="eu_milvus")
# Insert exported data in batches

The API surface is identical between Zilliz Cloud and self-hosted Milvus—the migration is primarily operational (infrastructure provisioning, capacity planning) rather than code changes.

Summary: Zilliz/Milvus for EU Developers

Zilliz introduces the most complex GDPR/sovereignty picture of any vector database in this series. The dual jurisdiction problem—US CLOUD Act plus China NSL—means EU data protection officers need a multi-jurisdiction risk analysis that standard CLOUD Act templates don't cover.

Do not use Zilliz Cloud if: you're storing embeddings derived from EU personal data and your organization has strict data sovereignty requirements. The dual jurisdiction exposure (US CLOUD Act + China NSL) creates a risk profile that is harder to address contractually than single-jurisdiction US vendors like Pinecone.

Consider Milvus self-hosted if: your application requires Milvus-scale performance (billion+ vectors), you have Kubernetes infrastructure on EU compute, and you're willing to implement the container registry mirror pattern to sever the operational Zilliz dependency.

Use Qdrant instead if: you need a sovereign managed vector database. German GmbH incorporation, EU data residency, zero dual-jurisdiction exposure. For most EU RAG applications, Qdrant is technically sufficient and operationally simpler.

Use pgvector if: your application runs on PostgreSQL. Adding pgvector to an existing EU-hosted Postgres cluster adds zero sovereignty overhead and no new vendor relationships.

The next (final) post in this series will publish the complete EU Vector Database Sovereignty Spectrum—a decision matrix across all five databases (Pinecone, Weaviate, Chroma, Zilliz/Milvus, and the EU-native alternatives) with scoring across all dimensions and implementation guidance for the most common EU RAG stack patterns.

sota.io is an EU-native managed PaaS — deploy any language, 100% GDPR, no CLOUD Act exposure, hosted on Hetzner Germany. Try sota.io free →