impala

Impala runs SQL directly against files already sitting in your data lake, and answers in seconds instead of minutes. Point it at Parquet or ORC files in HDFS or S3, register them in a Hive Metastore, and analysts query them with ordinary SQL from whatever BI tool they already use. Apache 2.0, nothing to buy.

Self-hosting is where the honesty starts. Impala is not one binary. You run a catalog daemon, a statestore, and an impalad process on every node in the cluster, plus the metastore and the storage layer underneath. It expects a cluster and it expects somebody who knows Hadoop era operations. Most teams running it in production got there through a Cloudera distribution rather than by assembling it themselves.

What you buy with that pain is latency. The daemons stay warm and queries compile to native code through LLVM, so dashboards hitting the same tables all day feel fast in a way Spark SQL does not. Solo developers and small teams: skip it, DuckDB does this on your laptop. Medium teams with a lake already on Hive Metastore or Iceberg: worth benchmarking against Trino. Large organizations already invested in the Hadoop stack: this is the reason to keep that investment.

The catch: the ecosystem moved on. Trino took the federated query story, DuckDB took the single machine story, and tagged Impala releases now arrive more than a year apart even though commits land weekly. It is a mature engine serving a shrinking audience, so choosing it today means accepting a smaller community than the alternatives have.