FerroDruid Container

Container build of FerroDruid. Deploy the Apache-Druid-spec-compatible real-time OLAP database as a single Rust binary on Amazon EKS via the included Helm chart. Speaks the Druid REST API, native query JSON, and Druid SQL; reads Druid segment v9. No JVM, no ZooKeeper, no six-process control plane. Metered per pod-hour, forces an admin-password rotation on first login, and fails closed without a Marketplace entitlement.

A classic Apache Druid cluster needs six or more JVM processes plus ZooKeeper plus an external metadata database and 16 GB+ of RAM before it serves a single query; FerroDruid Container replaces all of that with a single Rust binary running as one EKS pod. It is the same binary as the AMI build and serves all eight native query types (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary); runs Druid SQL (SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, 30+ functions, EXPLAIN PLAN FOR, an MSQ task endpoint, ~95% core SQL parity); exposes 40+ Druid-compatible REST endpoints; and reads Druid segment v9 (verified locally against segments written by Druid 31.0.2 and 35.0.1, and end-to-end from real AWS S3 deep storage: a Druid-31 segment, round-trip). The supported topology is a single node with SQLite metadata + local-filesystem deep storage; the Helm chart fails closed at template time on external metadata, external deep storage, `replicaCount>1`, and on injecting a paid product code into a source-available image. The admin account is force-rotated on first login (every endpoint returns 403 until rotated), and the paid container verifies entitlement via `RegisterUsage` at startup.

Highlights

Why it's cheaper

Assumes a real-time OLAP backend at ~1k events/sec on an existing EKS cluster.

Illustrative example. A minimal Apache Druid on EKS deploys broker / coordinator / historical / middleManager / overlord / router as six Pods, plus a ZooKeeper Pod and a RDS PostgreSQL metadata DB. FerroDruid Container provides the same wire-compatible API as a Rust single-process Pod, so the difference shows up directly in node cost. The EKS control plane fee is shared by both setups and therefore omitted.