Analytical data platforms on open table formats such as Apache Iceberg or Delta Lake over self-hosted object storage, queried with Trino, Spark or ClickHouse, instead of a proprietary cloud warehouse.
Analytics and regulatory reporting on an open lakehouse in banks and insurers: time travel for reproducing reports, fine-grained access control, lineage, retention rules and keeping data on infrastructure the firm controls.
Analytics on claims, clinical and research data: de-identified and identified zones, HIPAA access controls and audit, FHIR and HL7 sources, and research data sharing on self-hosted storage.
A shared analytics platform for agencies without warehouse lock-in: hosting rules, open formats for long-term records, cross-agency access control and publishing to open data portals.
Product and customer analytics at SaaS scale: per-tenant data separation, real-time and batch on the same tables, cost control compared with consumption-priced warehouses and feeding embedded analytics.
Combining sensor time series, quality, MES and ERP data: high-volume ingestion from plants, on-premises object storage, retention tiers and analytics that keep production data on site.
Storing and analyzing smart meter, grid and asset data: interval data volumes, long retention, separation from operational networks and forecasting workloads on Spark or Trino.
Moving analytics off US-hosted cloud warehouses to open formats on EU-controlled storage: what stays portable with Iceberg or Delta, catalog choices and documenting the transfers that remain.
Analytics on classified or isolated networks: on-premises object storage, importing engines and dependencies, catalog and access control without cloud identity and upgrades across the gap.
Deleting a person's rows from Iceberg or Delta tables for real: row-level deletes, why old snapshots still hold the data until they expire, orphan file cleanup, and the retention schedule that lets you prove erasure.
When dashboards and products need second-level freshness: streaming ingestion from Kafka into Iceberg or a real-time OLAP store such as ClickHouse, Druid or Pinot, and how to keep one source of truth.
Requirements to agree before building a lakehouse: table format, catalog, query engines, object storage, access control and lineage, data volumes and freshness, backups and the team that will run it.
Questions for partners proposing a lakehouse build: catalog and governance design, table maintenance, performance testing, cost model, migration from the current warehouse and handover, with red flags.
Cost components of a self-hosted lakehouse against a consumption-priced cloud warehouse: storage and compute nodes, engineering, table maintenance, support, and how query volume and concurrency drive each.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.