Grid-Ops Lakehouses for the 2026 Energy Transition.
We build utility lakehouses on Databricks or Azure with the IT/OT boundary designed in: a CIP DMZ landing pattern for historian and AMI feeds, medallion zones partitioned for years of 15-minute interval data, and the retention and lineage controls that rate cases and reliability filings depend on. The same zone design holds years of water-network telemetry — DMA flow, pressure, and CSO event-duration records — for water utilities.
Fragmented Silos
Legacy Utility systems and disconnected feeds.
DMZ-First Landing Zones
Interval-Optimised Storage Zones
Production Reality
Boundary-Aware Landing Zones
Boundary-Aware Landing Zones
Interval-Optimised Storage Design
Filing-Grade Platform Governance
Industry-Specific Friction Points
Interval Data Outgrows the Warehouse
AMI volumes compound fast — each 15-minute read is small, but a mid-size service territory accumulates tens of billions of reads a year, and rate-case analysis needs several years of them online. General-purpose warehouses price and partition that workload badly.
The Boundary Is a Platform Problem
Historian mirrors, jump hosts, and ad-hoc CSV exports accumulate wherever platform design ignores the electronic security perimeter. Every improvised workaround is another finding waiting for the next CIP assessment.
No Evidence Layer for Regulators
Reliability filings and prudency reviews expect a number's path from field device to filed figure to be reproducible. Platforms without built-in lineage and immutable retention turn every filing season into a forensic project.
How the Utility delivery flow works
This technical flow diagram reveals how Unolabs treats Utility data to deliver governed, production-ready outputs.
Source Layer
Utility IaC
Deploying the governed landing zone with the DMZ collection tier, private networking, and OT-side boundary controls scripted in.
Industry Logic
Zone Layout
Structuring bronze-to-gold zones for interval reads, historian tags, and asset records with partitioning tuned to meter-scale volumes.
Governance Hardening
Wiring lineage, retention, and role-based access so billing-grade and reliability data carry their evidence with them.
Activation
Platform Ops
Standing up cost attribution and pipeline health monitoring so storm-season ingest spikes stay visible and budgeted.
How the work is engineered for Utility
DMZ-First Landing Zones
We provision the utility platform as code with the CIP DMZ collection tier designed in, so OT-originated historian and meter data lands through governed one-hop paths rather than improvised exports.
Interval-Optimised Storage Zones
We lay out bronze-to-gold zones partitioned by meter, feeder, and read timestamp, tuned so multi-year interval scans for load research and rate design stay fast and affordable.
Filing-Grade Governance
We engineer platform-level lineage, retention schedules, and access controls that produce regulator-ready evidence for reliability and billing data as a by-product of normal operation.
Where the Real Work Is
Interval Storage Is an Economics Problem
Two query patterns fight over the same data: operations wants the last few weeks for one meter instantly, while load research and rate design scan whole territories across multiple years. A single storage layout serves both badly. We tier deliberately — recent months hot, working years warm, older cycles in cheap archival tiers that remain queryable — and pre-compute transformer- and feeder-grain aggregates so the expensive territory-wide scans hit compact tables instead of raw reads.
The DMZ Tier Is Platform, Not Plumbing
The collection tier sitting in the CIP DMZ is usually the least-owned component in the estate: built once during an integration project, then orphaned. We treat it as a first-class platform tier with sizing, monitoring, patch ownership, and failure modes designed up front — including what happens downstream when the DMZ broker lags or fails. That clarity matters doubly because intermediate systems at the boundary attract both attacker interest and auditor attention.
Storm Season Is the Real Load Test
A major event multiplies ingest for exactly the hours when the platform matters most: last-gasp bursts, OMS churn, and every analyst refreshing at once. Elastic capacity handles the surge only if quotas, autoscaling limits, and cost guardrails were decided on a calm day — otherwise the choice is between throttled pipelines and an unbudgeted cloud bill. We size for the event profile, rehearse replay and backfill, and cap spend with alerts rather than surprises.
Visible work products, not vague advice
Each deliverable is designed to be used by Utility architects, engineers, data owners, and operations teams after the engagement ends.
How We Measure the Platform
Platform health is measured against your workloads, not synthetic benchmarks. We baseline each measure on your current estate during the sizing workshop and track it through every release.
Multi-year scan cost and runtime
A standard load-research query — several years of interval data across the territory — is benchmarked at baseline and re-run after each storage change, so tiering decisions are judged on evidence.
Ingest lag under event load
Minutes from source availability to queryable data, tracked as separate quiet-day and storm-day distributions — a platform that is only fast on calm days fails its actual mission.
Evidence retrieval time
Elapsed time to produce the full lineage behind a filed or billing-grade figure, from request to document — the honest test of whether governance tooling works or just exists.
Storage cost per meter-year
Fully attributed storage spend divided by meters and retention years, trended as history accumulates so multi-year retention obligations stay affordable by design.
Frequently Asked Questions
Which stacks do you build utility lakehouses on?
Primarily Databricks and Azure, with Snowflake and Microsoft Fabric where they fit the estate — the choice follows your existing cloud commitments and licensing, not our preference. The patterns that matter — DMZ landing tier, interval-tuned partitioning, filing-grade lineage — are portable across all of them.
How do you keep years of interval data affordable to query?
Three levers together: storage tiering that moves cold billing cycles onto cheap tiers without losing queryability, partitioning and file compaction tuned to meter-and-timestamp access patterns, and pre-aggregated marts resolved to transformer and feeder level so most analytical questions never touch raw reads. The result is measured against a benchmarked reference query, not asserted.
Who owns the DMZ collection tier after you leave?
Your teams — and the design assumes it. We build the tier with your OT security group at the table, document its sizing, monitoring, and patch responsibilities in the platform runbook, and hand over infrastructure-as-code rather than a hand-built appliance. Ownership boundaries between OT, security, and platform teams are written down before go-live, not discovered during the first incident.
How an engagement starts
The first session is a sizing workshop: bring meter counts, read frequency, and your retention obligations, and we sketch the landing-zone and storage-tier design in enough detail to take to your architecture review board.
Interested in the full industry blueprint?
We have deeper technical documentation for Enterprise Data Platform Engineering for Utility in the Utility sector.
Bring your AMI interval-read volumes. We'll size the grid lakehouse in the first session.