Infrastructure State as a Data Asset
When infrastructure state lives in a database, it integrates with every tool the organization already uses: Grafana, Datadog, PagerDuty, Jira, SIEM platforms. When it lives in JSON files on S3, only Terraform can read it.
Visibility and Observability
Standard questions at scale, and what it takes to answer them today:
How many EC2 instances exist across all teams?
Write a script that pulls 40 state files from S3, parses each one, aggregates. Takes hours to build, breaks when workspaces change.
Which resources does the platform team own?
Dig through repository directories. No structured mapping exists.
What changed in production last Friday at 3 PM?
Run git blame on the state file and attempt to read a 200MB JSON diff.
With Oxid
These queries pipe directly into Grafana, Datadog, or any BI tool. Infrastructure becomes queryable data, not buried JSON files.
Change Flow and Audit Trail
The standard change flow today: a developer opens a PR, CI runs terraform plan, someone reviews a wall of plan output, the PR merges, and apply runs. After apply, the only record is that the state file changed. No actor, no reason, no approval chain.
When compliance asks “who approved the security group change on January 15th,” the answer is: dig through GitHub PRs, hope the plan output was saved somewhere, and cross-reference with the state file diff.
Database-backed audit trail
- >Every resource change is a database transaction with metadata: actor, timestamp, diff, apply run ID, and originating PR
- >Change history is tracked per resource, not per workspace
- >“Show every change to aws_security_group.prod in the last 90 days” resolves with one query
- >SOC 2 and HIPAA auditors expect evidence of change control with timestamps, actors, and before/after state. A database provides this natively. A versioned S3 bucket with JSON blobs does not.
Blast Radius Control
One workspace equals one state file equals one lock equals one blast radius. A bad apply to the “networking” workspace can touch VPCs, subnets, route tables, and NAT gateways all at once.
The standard mitigation is splitting infrastructure into more workspaces. More workspaces means more state files, more complexity, more cross-workspace data sources, and slower plans. The workaround compounds the original problem.
Database-backed blast radius
- >Row-level locking scopes applies to individual resources or resource groups without splitting workspaces
- >“Apply only the 3 security group changes, not the VPC changes” is possible because state is not a single blob
- >A failed apply on one resource does not hold a lock that blocks every other team
Drift Detection at Scale
Drift detection with Terraform means running terraform plan on every workspace periodically. State locks are held the entire time, blocking real deploys.
0
workspaces
Scanned per cycle
0
min each
Average plan duration
0
hours
Total compute per drift check
Most organizations skip drift detection entirely. Drift is discovered when something breaks.
Database-backed drift detection
Batch-scoped
Check 100 resources at a time with no global lock
Continuous
Background process checking 5% of resources every hour
Priority-tiered
Production every hour, staging daily, development weekly
Immediate alerting
Alert on drift as detected, not on next plan run
Cost Attribution and Resource Inventory
Answering “how much infrastructure does each team own” typically requires custom tooling that parses state files, maps to cost explorer tags, and aggregates manually. Checking for untagged resources means pulling every state file and inspecting each one.
Untagged resources (compliance violation)
Resource count by type (capacity planning)
Resources by team (cost attribution)
Live data, always current, no ETL pipeline needed. Connects directly to existing dashboards.
Multi-Team Governance
Policy enforcement today runs against plan output via OPA or Sentinel, which amounts to text parsing. Access control is limited to S3 bucket-level permissions: either full access to the state file or none. Cross-team dependencies require terraform_remote_state data sources, creating tight coupling between workspaces.
Policy Enforcement
Policies query the database directly. Example: block any apply that creates an aws_instance without a CostCenter tag.
Row-Level Access Control
Team A has read/write access to its own resources, read-only access to shared networking resources, and no access to Team B's resources. Granularity is per resource, not per state file.
Cross-Team References
Cross-team references are standard queries. No special data sources, no coupling between workspaces, no brittle remote state dependencies.
──COMPARISON
Side by Side
| Capability | Terraform (JSON blob) | Oxid (Database) |
|---|---|---|
| Visibility | Parse state files with custom scripts | SQL queries, pipe to any dashboard |
| Audit Trail | S3 versioning + git blame | Per-resource change history with actor and timestamp |
| Blast Radius | Split workspaces (more complexity) | Row-level locking (native granularity) |
| Drift Detection | Full plan per workspace, takes hours | Incremental, continuous, completes in minutes |
| Cost Attribution | Custom ETL pipelines | Live SQL queries against current state |
| Access Control | S3 bucket policies (all-or-nothing) | Row-level security (per resource, per team) |
| Compliance | S3 bucket versioning as evidence | Audit table with every change, actor, and timestamp |
Infrastructure state becomes a first-class data asset that integrates with every tool the organization already uses. Today it is trapped in JSON files on S3 that only Terraform can read. A database changes that.