Intent vs. Reality: Bridging the Structural Gap Between Configuration State and Physical Topology
Every network engineer has lived through a haunting realization. You look at an official network inventory document or a central tracking ledger, and it tells you one thing. Then you log into a physical core switch CLI, execute a manual diagnostic command, and find something entirely different. The static documentation states that a specific port is completely isolated, but the physical, live reality shows it is actively broadcasting traffic across a multi-tenant corridor.
This disconnect highlights a foundational crisis in modern infrastructure management: the structural delta between operational intent and physical reality. In modern enterprise infrastructure, this widening gap is the primary breeding ground for unexpected downtime, routing loops, and hidden vulnerabilities. Legacy network management tools fail to fix this issue because they try to treat two fundamentally different data profiles as if they were the exact same thing. They attempt to force the abstract, relational rules of network design and the fluid, interconnected physical topology of physical hardware cables into a single software storage model.
Why a Single Database Cannot Support a Network Digital Twin
The data describing what a network should do is fundamentally different from the mathematical data describing how packets actually traverse physical circuits. Forcing one database engine to handle both workloads results in massive query latencies, fragile table architectures, and a catastrophic inability to detect configuration drift before human operators report an outage.
Managing infrastructure rules demands a data environment optimized for absolute transactional safety. Conversely, mapping a live topology demands a system optimized for rapid path tracing and multi-hop relationship indexing.
OmniTwin solves this structural challenge by engineering a dual-engine data tier. Instead of relying on a single, compromised storage architecture, our platform deploys two specialized database engines working in absolute synchronization. This dual model completely decouples abstract intent from live reality.
The OmniTwin Dual-Engine Architecture
To maintain a true computational twin that can validate network changes at the microsecond level, OmniTwin pairs an enterprise relational engine with a native, high-performance graph database.
| Database Engine | Architecture Role inside OmniTwin | Key Data Types & Operations |
|---|---|---|
| PostgreSQL 17 | The Absolute Source of Intent | Tracks tenant spaces, multi-tenant boundaries, approved IP prefixes, and administrative access control policies. |
| Neo4j | The Absolute Source of Reality | Maps live interface states, routing neighbors, VLAN propagation boundaries, and physical hardware links as explicit nodes and edges. |
1. The Intent Tier: PostgreSQL 17 & Semantic Vectors
PostgreSQL serves as our immutable anchor for transactional rules. Within this layer, OmniTwin stores explicit system policies, multi-tenant virtual routing and forwarding (VRF) schemas, and authorized IPAM boundaries.
We also use pgvector to store semantic vector embeddings. These embeddings translate high-level engineering requirements and written compliance specifications into structured mathematical data objects. This allows our Go-based control plane to interpret the human intent behind a configuration with absolute clarity, ensuring our autonomous agents know exactly what the network is authorized to look like at any given millisecond.
2. The Reality Tier: Neo4j Topology Graphs
Instead of forcing deeply nested networking pathways into rigid database rows and columns, Neo4j treats every physical switch, router, cloud gateway, and local database container as an independent node.
The physical and logical connections between these devices are mapped as explicit relationship edges. This graph matrix tracks real-time link states and telemetry anomalies. When our automated agents execute high-throughput path traversal algorithms to simulate how a packet moves across the fabric, Neo4j calculates the exact path across the multi-vendor network topology instantly.
Eliminating State Drift via Continuous Reconciliation
The true power of the OmniTwin control plane emerges from the continuous reconciliation loop running between these two distinct environments. Our background daemons constantly cross-reference the relational intent state in PostgreSQL with the physical graph reality running in Neo4j.
How the Sync Engine Prevents Downtime:
If an unauthorized configuration change occurs on a remote switch, or if a physical path drift violates a security embedding, OmniTwin catches the delta at the software layer. By comparing runtime topology against the validated mathematical model, the engine identifies the structural drift immediately, alerting systems engineers or triggering automated isolation routines before the mismatch can cause a single packet drop.
By decoupling intent from reality at the database level, OmniTwin provides modern infrastructure teams with a clear, mathematically verified view of their entire environment, turning network operations into a precise science.