Component-level architectural correction (two changes): 1. MinIO → SeaweedFS as unified S3 encapsulation layer The old design used MinIO for in-cluster S3 plus separate cold-tier configuration scattered across consumers. The new design positions SeaweedFS as the single S3 encapsulation layer: every Catalyst component talks to one endpoint (seaweedfs.storage.svc:8333). SeaweedFS internally handles hot tier (in-cluster NVMe), warm tier (in-cluster bulk), and cold tier (transparent passthrough to cloud archival storage — Cloudflare R2 / AWS S3 / Hetzner Object Storage / etc., chosen at Sovereign provisioning). One audit/lifecycle/encryption boundary instead of N. No Catalyst component talks to cloud S3 directly anymore — Velero, CNPG WAL archive, OpenSearch snapshots, Loki/Mimir/Tempo, Iceberg, Harbor blob store, Application buckets all share one S3 surface. 2. Apache Guacamole added as Application Blueprint §4.5 Communication Clientless browser-based RDP/VNC/SSH/kubectl-exec gateway. Keycloak SSO, full session recording to SeaweedFS for compliance evidence (PSD2/DORA/SOX). Composed into bp-relay. Replaces VPN+native-client distribution for auditable remote access. Component changes: - DELETED: platform/minio/ - CREATED: platform/seaweedfs/README.md (unified S3 + cold-tier encapsulation; bucket layout; multi-region replication via shared cold backend; migration-from-MinIO section) - CREATED: platform/guacamole/README.md (clientless remote-desktop gateway; GuacamoleConnection CRD; compliance integration via session recordings) Doc updates: PLATFORM-TECH-STACK §1+§3.5+§4.5+§5+§7.4; TECHNOLOGY-FORECAST L11+mandatory+a-la-carte counts (52 → 53); ARCHITECTURE §3 topology; SECURITY §4 DB engines; SOVEREIGN-PROVISIONING §1 inputs; SRE §2.5+§7; IMPLEMENTATION-STATUS §3; BLUEPRINT-AUTHORING stateful examples; BUSINESS-STRATEGY 13 component-count anchors + Relay product line; README.md backup row; CLAUDE.md folder count. Component README updates (S3 endpoint + dependency renames): cnpg, clickhouse, flink, gitea, iceberg, harbor, grafana, livekit, kserve, milvus, opensearch, flux, stalwart, velero (substantive rewrite of velero — now writes exclusively to SeaweedFS with cold-tier auto-routing). Products: relay, fabric. UI scaffold: products/catalyst/bootstrap/ui/src/shared/constants/components.ts — minio entry replaced with seaweedfs; velero+harbor deps updated; new guacamole entry added. VALIDATION-LOG entry "Pass 104 — MinIO → SeaweedFS swap + Guacamole add" captures the encapsulation principle and adds Lesson #22: storage tier policy belongs at the encapsulation boundary, not inside every consumer. Verification: zero remaining MinIO references in canonical docs (one intentional retention in TECHNOLOGY-FORECAST L37 explaining the swap); 53 platform/ folders matching all "53 components" anchors; bp-relay composition includes guacamole. |
||
|---|---|---|
| .. | ||
| README.md | ||
Milvus
Vector database for similarity search. Application Blueprint (see docs/PLATFORM-TECH-STACK.md §4.6). Backbone of RAG pipelines in bp-cortex (paired with BGE embeddings).
Status: Accepted | Updated: 2026-04-27
Overview
Milvus provides high-performance vector similarity search for RAG, recommendation systems, and AI applications.
flowchart TB
subgraph Milvus["Milvus Cluster"]
Proxy[Proxy]
QueryNode[Query Nodes]
DataNode[Data Nodes]
IndexNode[Index Nodes]
end
subgraph Storage["Storage"]
etcd[etcd<br/>Metadata]
SeaweedFS[SeaweedFS<br/>Object Storage]
end
App[Application] --> Proxy
Proxy --> QueryNode
Proxy --> DataNode
DataNode --> SeaweedFS
QueryNode --> SeaweedFS
Proxy --> etcd
Why Milvus?
| Feature | Benefit |
|---|---|
| Billion-scale vectors | Enterprise-grade scalability |
| Hybrid search | Dense + sparse vectors |
| Multiple indexes | IVF, HNSW, DiskANN |
| GPU acceleration | Optional GPU indexing |
| Cloud-native | Kubernetes-native deployment |
Use Cases
| Use Case | Description |
|---|---|
| RAG | Document chunk retrieval |
| Semantic search | Natural language queries |
| Recommendation | Similar item retrieval |
| Image search | Visual similarity |
| Anomaly detection | Outlier identification |
Configuration
Helm Values
cluster:
enabled: true
etcd:
replicaCount: 3
persistence:
size: 10Gi
seaweedfs:
enabled: false # Use external SeaweedFS
externalS3:
enabled: true
host: seaweedfs.storage.svc
port: 9000
accessKey: "" # From ESO
secretKey: "" # From ESO
bucketName: milvus
proxy:
replicas: 2
resources:
requests:
cpu: 500m
memory: 1Gi
queryNode:
replicas: 2
resources:
requests:
cpu: 1
memory: 4Gi
dataNode:
replicas: 2
resources:
requests:
cpu: 500m
memory: 2Gi
indexNode:
replicas: 1
resources:
requests:
cpu: 1
memory: 4Gi
Collection Schema
from pymilvus import Collection, FieldSchema, CollectionSchema, DataType
fields = [
FieldSchema(name="id", dtype=DataType.VARCHAR, max_length=64, is_primary=True),
FieldSchema(name="document_id", dtype=DataType.VARCHAR, max_length=64),
FieldSchema(name="chunk_index", dtype=DataType.INT64),
FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=65535),
FieldSchema(name="source", dtype=DataType.VARCHAR, max_length=32),
FieldSchema(name="dense_vector", dtype=DataType.FLOAT_VECTOR, dim=1024),
FieldSchema(name="sparse_vector", dtype=DataType.SPARSE_FLOAT_VECTOR),
]
schema = CollectionSchema(fields, description="Document chunks")
collection = Collection("documents", schema)
Index Types
| Index | Use Case | Memory |
|---|---|---|
| HNSW | High recall, fast query | High |
| IVF_FLAT | Balanced | Medium |
| IVF_SQ8 | Memory-efficient | Low |
| DiskANN | Billion-scale | Disk-based |
| GPU_IVF_FLAT | GPU-accelerated | GPU memory |
Create Index
index_params = {
"metric_type": "COSINE",
"index_type": "HNSW",
"params": {"M": 16, "efConstruction": 256}
}
collection.create_index("dense_vector", index_params)
Hybrid Search
Combine dense and sparse vectors:
from pymilvus import AnnSearchRequest, WeightedRanker
# Dense search
dense_req = AnnSearchRequest(
data=[dense_vector],
anns_field="dense_vector",
param={"metric_type": "COSINE", "params": {"ef": 64}},
limit=20
)
# Sparse search
sparse_req = AnnSearchRequest(
data=[sparse_vector],
anns_field="sparse_vector",
param={"metric_type": "IP"},
limit=20
)
# Combine with weighted ranker
results = collection.hybrid_search(
[dense_req, sparse_req],
rerank=WeightedRanker(0.7, 0.3),
limit=10
)
Partition Strategy
# Partition by source for isolation
collection.create_partition("compliance")
collection.create_partition("infrastructure")
collection.create_partition("ephemeral")
# Query specific partition
results = collection.search(
data=[query_vector],
anns_field="dense_vector",
partition_names=["compliance"],
limit=10
)
Monitoring
| Metric | Query |
|---|---|
| Query latency | milvus_proxy_search_latency |
| Insert rate | milvus_datanode_flush_buffer_op_total |
| Memory usage | milvus_querynode_memory_usage |
| Collection size | milvus_datacoord_stored_binlog_size |
Backup
Via Velero with SeaweedFS storage:
# Milvus data is stored in SeaweedFS
# SeaweedFS is backed up via Velero to Archival S3
Consequences
Positive:
- Billion-scale vector search
- Hybrid dense + sparse search
- Multiple index types
- Kubernetes-native
- Active community
Negative:
- Complex distributed architecture
- Resource-intensive for large collections
- Learning curve
Part of OpenOva