Pattern Name: Semantic Memory for Operational Intelligence
We deploy vector databases as the semantic memory layer between operational systems and LLMs. In energy operations, you're constantly asking questions like "show me all incidents similar to this voltage anomaly" or "what procedures relate to transformer maintenance under these conditions." Traditional SQL databases force you into rigid schema matching. Vector databases let you find conceptually similar content even when the exact keywords don't match.
The pattern applies when you need similarity search across unstructured operational data — alarm logs, maintenance procedures, engineering drawings, regulatory filings, incident reports. We've deployed this at utilities handling 50,000+ daily SCADA alarms and oil & gas facilities with 30 years of well completion reports.
The Problem: SQL Can't Do Semantic
Your operational data doesn't fit into neat relational schemas. An operator searches for "generator trip" but the relevant procedure uses "unit separation event." A maintenance tech looks for "transformer oil analysis" but historical records say "insulating fluid diagnostics." String matching fails. Full-text search helps but still misses conceptual relationships.
Worse, in RAG architectures where you're feeding context to LLMs, you need to retrieve the most semantically relevant chunks from millions of document fragments. A traditional database would require you to anticipate every possible query pattern. That's impossible when dealing with natural language questions about 40 years of operational history.
We tried building this with PostgreSQL full-text search and pgvector at a West Coast utility. Query latency for semantic search across 8 million document chunks: 4-12 seconds. Unacceptable for an operator troubleshooting a grid event. We needed sub-100ms retrieval.
Solution Architecture: Vector DB as Semantic Index
The architecture has three layers:
Embedding Generation Layer
You run an embedding model — we typically use nomic-embed-text v1.5 through Ollama — that converts text chunks into 768-dimensional vectors. Each vector captures semantic meaning. Similar concepts cluster in vector space even if they use different terminology.
For a maintenance procedure, you might chunk it into 500-token segments, embed each chunk, and store the vectors with metadata (document ID, section, timestamp, equipment tag). The embedding model runs locally in your OT environment. No cloud APIs. No data exfiltration.
Vector Storage and Retrieval
The vector database stores these embeddings with HNSW or IVF indexes optimized for approximate nearest neighbor search. When a query comes in, you embed the query text and find the closest vectors in semantic space. This returns the most conceptually relevant chunks, not just keyword matches.
We run Qdrant for this layer in most deployments. Written in Rust, single binary, uses memory-mapped files for performance. At a Texas utility, we're indexing 12 million vectors (alarm descriptions, procedures, incident reports) with p99 retrieval under 35ms. That's production-ready for real-time operator assistance.
Qdrant supports filtered search — you can constrain results by metadata like "only procedures for 138kV equipment" or "incidents from the last 90 days." This matters in NERC CIP contexts where you need to enforce data boundaries.
Integration Layer
Vector DB sits between your operational systems and LLM applications. An operator asks a question in natural language. Your application embeds the question, queries the vector DB for top-k relevant chunks (we typically use k=5-10), assembles those chunks into context, and feeds them to the LLM for answer generation.
The vector DB is read-heavy, write-occasionally. You're constantly querying it but only updating vectors when new documents arrive or existing ones change. This asymmetry lets you optimize for retrieval performance.
Implementation: What Actually Works
We've deployed four vector databases in production energy environments. Here's what we've learned.
Qdrant: Our Default Choice
Qdrant wins for air-gapped OT deployments. Single Rust binary, no JVM, no complex dependencies. Memory usage is predictable — roughly 1.5GB RAM per million 768-dimensional vectors with HNSW indexing. You can estimate capacity accurately.
Configuration that works for energy sector scale:
- HNSW index with m=16, ef_construct=100 for build, ef=64 for search
- Memory-mapped storage on NVMe SSDs (p99 latency drops 40% vs. spinning disks)
- Quantization disabled (scalar quantization saves RAM but costs 10-15% recall on our embedding models)
Qdrant's HTTP API is straightforward. No ORMs, no abstraction layers. You POST vectors, you GET similar vectors. We integrate it with n8n workflows for automated document ingestion and with AnythingLLM for RAG.
Downside: Qdrant clustering requires commercial license. For high-availability deployments, you're running active-passive with filesystem replication. Not elegant but acceptable for OT requirements.
Weaviate: When You Need Hybrid Search
Weaviate combines vector search with BM25 keyword search. If you're migrating from Elasticsearch and need backward compatibility with keyword queries, Weaviate provides a transition path. You can run hybrid queries that blend semantic similarity with traditional full-text matching.
We deployed Weaviate at a renewable energy company searching solar panel warranty claims. Users wanted both semantic search ("find claims about inverter failures") and precise keyword matching ("serial number XYZ-123"). Weaviate's alpha parameter lets you weight vector vs. keyword components.
Trade-off: Weaviate uses more memory than Qdrant for equivalent vector counts. JVM-based, so you're tuning garbage collection. Startup time in air-gapped environments can hit 2-3 minutes as it initializes Java heap. For edge deployments on modest hardware, that's a problem.
Milvus: Trillion-Scale That We Don't Need
Milvus is built for hyperscale — billions of vectors, distributed clusters, GPU acceleration. Impressive engineering but overkill for energy sector deployments. Our largest production index is 35 million vectors. Milvus shines at 100M+ vectors.
We tested Milvus for a multinational oil & gas operator who wanted to index every well log from 50 years of drilling. Even there, 80 million vectors fit comfortably in Qdrant on a single server with 128GB RAM. The operational complexity of running Milvus (etcd cluster, MinIO for object storage, Pulsar for message queues) wasn't justified.
If you're genuinely approaching billion-vector scale, consider Milvus. Otherwise, simpler tools win.
ChromaDB: Development and Prototyping
ChromaDB is Python-native with zero-config local mode. Perfect for prototyping RAG applications before production deployment. We use it in development environments where data scientists are experimenting with embedding models and chunking strategies.
Chroma's limitations hit hard in production. No built-in authentication, limited scalability, performance degrades past 10 million vectors. Treat it as a development tool, not production infrastructure.
NERC CIP and Data Sovereignty
Vector databases in OT environments must respect cyber security boundaries. NERC CIP-005 and CIP-007 matter.
Air-Gapped Deployment
All embedding generation happens locally. We run Ollama with nomic-embed-text inside the Electronic Security Perimeter. No API calls to OpenAI or Cohere. The embedding model is 275MB — fits on a thumb drive, verifiable hash, no license restrictions.
Qdrant runs entirely in-memory or on local NVMe. No cloud sync, no external dependencies post-installation. Your vectors never leave the facility.
Access Control
Qdrant supports API key authentication but no fine-grained RBAC. We layer nginx in front with client certificates mapped to user roles. You can enforce "only control room operators access SCADA alarm embeddings" at the proxy layer.
Metadata filtering provides another security boundary. Tag every vector with clearance level, equipment classification, facility ID. Query-time filters ensure users only retrieve vectors they're authorized to see.
Audit Requirements
Vector databases don't inherently log queries. For NERC CIP compliance, we run Qdrant behind a logging proxy that captures every search query, result count, and requesting user. Logs feed into your SIEM for audit trails.
One gotcha: embeddings themselves can leak information. If an attacker extracts your vector database file, they can perform nearest-neighbor searches even without the original text. Encrypt at rest. We use LUKS full-disk encryption on Qdrant volumes.
Performance Characteristics
Real numbers from production deployments:
Qdrant at 12M vectors (Texas utility)
- Hardware: Dell R750, 64GB RAM, 2x 1TB NVMe RAID-1
- Embedding model: nomic-embed-text-v1.5 (768 dimensions)
- Index: HNSW m=16, ef=64
- Query latency p50: 18ms, p99: 35ms
- Throughput: 850 queries/second sustained
- Memory: 22GB resident set size
Weaviate at 4M vectors (renewable energy)
- Hardware: HPE ProLiant, 128GB RAM, NVMe
- Embedding model: all-MiniLM-L6-v2 (384 dimensions)
- Hybrid search alpha=0.7 (70% vector, 30% BM25)
- Query latency p50: 45ms, p99: 120ms
- Throughput: 320 queries/second
- Memory: 38GB (JVM heap + vector index)
Embedding Generation (Ollama/nomic-embed)
- Hardware: Same as Qdrant above
- Throughput: 2,400 chunks/second (batch=32)
- Single chunk latency: 12-15ms
- Memory: 4GB model loaded
For comparison, pgvector on the same 12M vector dataset delivered p99 latency of 4-8 seconds. Purpose-built vector databases aren't just faster — they're a different performance class.
Integration with Knowledge Graphs
Vector databases complement graph databases; they don't replace them. At a West Coast utility, we run both Qdrant and Neo4j.
Neo4j stores the operational knowledge graph: equipment hierarchy, spatial relationships, causal chains from root cause analyses. Qdrant stores semantic embeddings of documents about that equipment.
When an operator searches for "similar incidents to transformer T-142 voltage sag," we query Qdrant for semantically similar incident reports, then use Neo4j to filter results by graph proximity (same substation, same voltage level, connected equipment). The combination is more powerful than either alone.
Neo4j 5.x added vector index support, letting you store embeddings directly in graph nodes. We tested it. Performance is acceptable for graphs under 1 million nodes but degrades as graph size grows. For dedicated semantic search at scale, Qdrant still wins. For small-scale RAG tightly coupled to graph traversal, Neo4j's built-in vectors simplify architecture.
Chunking Strategy Matters More Than You Think
Vector database performance depends on chunking quality. We've learned this the hard way.
Chunk Size
Too small (100-200 tokens): you lose context, retrieval becomes noisy. Too large (1000+ tokens): individual chunks contain multiple concepts, relevance scoring suffers.
Sweet spot for procedures and technical documents: 400-600 tokens with 50-token overlap. For alarm logs and short-form content: 200-300 tokens.
Chunk Boundaries
Don't chunk mid-sentence. We use semantic chunking based on paragraph breaks and section headers. A maintenance procedure chunked by arbitrary token count produces fragments like "...torque to 85 ft-lbs. Step 14: Verify" — useless out of context.
We built a chunking pipeline in n8n that respects document structure: section headers, procedure steps, table boundaries. Retrieval quality improved 30% measured by operator feedback.
Metadata Enrichment
Every chunk gets metadata: source document, timestamp, equipment tags, document type, author. This enables filtered searches and improves ranking. When retrieving context for an LLM, you can prioritize recent procedures over archived versions, or weight results from subject matter experts.
Cost Model
Vector databases are RAM-intensive. Budget 1.5-2GB per million 768-dimensional vectors for HNSW indexes. Our 12M vector deployment uses 64GB server, leaving headroom for OS and application processes.
NVMe storage is cheap — 1TB NVMe is under $100. The constraint is RAM, not disk. If you're indexing 50M vectors, you need 128GB+ RAM. Plan accordingly.
Embedding generation is CPU-bound. With Ollama on CPU (no GPU), we get 2,400 chunks/second. That's 8.6 million chunks per hour. Re-embedding your entire corpus is feasible in hours, not days. GPU acceleration helps but isn't required for batch processing.
Operational cost is minimal. Qdrant uses 0.5-1.5% CPU during query load, 2-3% during index updates. Power draw is negligible compared to SCADA servers.
When Not to Use Vector Databases
Vector databases aren't universal. Don't use them for:
- Transactional data (use PostgreSQL)
- Time-series metrics (use InfluxDB or TimescaleDB)
- Exact-match lookups (use Redis or traditional indexes)
- Hierarchical or relational queries (use Neo4j for graphs, PostgreSQL for relations)
Vector databases solve one problem: finding semantically similar content in high-dimensional space. If you're not doing similarity search, you don't need a vector database.
The Verdict
For energy sector AI deployments requiring semantic search and RAG, vector databases are non-negotiable infrastructure. We default to Qdrant for production — single binary, predictable performance, straightforward deployment in air-gapped OT environments.
Weaviate makes sense if you're transitioning from Elasticsearch and need hybrid search during migration. Milvus is over-engineered for typical energy sector scale. ChromaDB is a prototyping tool, nothing more.
Architecture pattern: run local embedding generation with Ollama, store vectors in Qdrant, integrate with n8n for document ingestion and AnythingLLM for RAG interfaces. This stack survives NERC CIP audits, delivers sub-50ms retrieval, and scales to tens of millions of vectors on commodity servers.
The semantic memory pattern transforms how operators interact with decades of operational knowledge. Instead of remembering which manual contains the transformer maintenance procedure, they ask in natural language and get the right context immediately. That's the architectural shift vector databases enable.