Data Engineering
June 8, 2026
9 min read

Building a Data Lakehouse on Kubernetes with Spark, Trino, and MinIO

Why Lakehouse Instead of Warehouse or Lake

Traditional data warehouses require loading data into a rigid schema before it can be queried, which is expensive and slow for the raw, semi-structured data that AI and analytics teams increasingly work with. Data lakes solve that by storing everything in object storage in its native format, but lose the transactional guarantees and query performance that made warehouses useful in the first place. A lakehouse architecture keeps data in open formats in object storage while adding a table format layer — Iceberg or Delta Lake — that provides ACID transactions, schema evolution, and time travel on top of that storage, without requiring a separate copy of the data for analytics.

Recommended Architecture

  • Kafka — streaming ingestion for real-time data sources
  • Apache Spark — distributed batch and stream processing
  • MinIO — S3-compatible object storage as the lakehouse foundation
  • Trino — federated SQL query engine for interactive analytics
  • Superset — BI dashboards and visualization

Data flows in through Kafka for real-time sources or direct writes for batch sources, is processed and written to MinIO by Spark jobs, and is queried by Trino for both ad hoc analysis and scheduled reporting, with Superset providing the dashboard layer on top.

MinIO as the Storage Foundation

Running MinIO on Kubernetes rather than relying solely on a managed cloud object store keeps the entire stack portable and avoids per-request egress charges when Spark and Trino read the same data repeatedly during iterative development. MinIO's S3 API compatibility means every tool in the stack — Spark, Trino, and most ML frameworks — treats it exactly like AWS S3, so pipelines built against MinIO in development move to any S3-compatible target in production without code changes.

Trino and Spark: Query vs. Processing

It's a common mistake to treat Spark and Trino as interchangeable — they're optimized for different jobs. Spark is a processing engine: it excels at large batch transformations, joins across huge datasets, and iterative machine learning workloads where a job might run for minutes or hours. Trino is a query engine: it's optimized for interactive, low-latency SQL against data that's already in a queryable state, federating across multiple sources — MinIO, PostgreSQL, Kafka topics — in a single query. Using Trino for a multi-hour ETL job or Spark for a dashboard's live query will both work, but neither is the efficient choice for that task.

Recommended NexNodo Deployment

This is a CPU-bound workload — no GPU is required. The recommended deployment is a Managed Kubernetes CPU XL:

  • 3 Worker Nodes
  • 8 vCPU / 16 GB RAM / 320 GB SSD per node
  • $0.369/hr or $269/mo

This configuration handles TB-scale datasets with both real-time and batch processing, and supports multiple concurrent analytics queries without contention.

Deploy Faster

The Data & AI Lakehouse Template deploys Kafka, Spark, MinIO, Trino, and Superset together on Kubernetes, so your data engineering team can start building pipelines instead of wiring up infrastructure.