Druid Bundle Laravel Package

Product Decisions This Supports

• Real-time analytics feature bets: This bundle is a thin integration layer between a Symfony application and an Apache Druid cluster (query execution, client configuration, possibly a query builder). It supports the decision to ship user-facing or internal dashboards backed by Druid — funnel analysis, event-stream exploration, operational monitoring — without building a bespoke PHP client from scratch.
• Build vs. buy vs. borrow: It is a "borrow" option. If your roadmap includes time-series/event analytics and your stack already runs Druid, this is a candidate to satisfy the integration workstream cheaply. If you have not committed to Druid, this package should not be the reason you do — the dependency should follow the datastore decision, not drive it.
• Scope containment for the analytics squad: A ready-made client lets you keep engineering effort on query semantics, caching, and UX rather than HTTP transport, connection pooling, and error mapping. That is a roadmap accelerator of weeks, not months.
• Architecture/platform decision: Adopting it implicitly commits you to Symfony's bundle/service-container conventions. That is a platform decision with long-tail implications for hiring, onboarding, and future framework upgrades.
• Not a decision driver: With zero stars, zero dependents, and no visible adoption, this package should not influence product strategy, vendor selection, or pricing. It is an implementation detail at best.

When to Consider This Package

Consider it only when all of the following hold:

• Your application is Symfony, not Laravel. Despite being catalogued here as a Laravel/PHP package, this is a Symfony bundle (TmkDruidBundle) and will not drop into a Laravel service provider architecture without meaningful adaptation. If you are on Laravel, this is a rewrite, not an install.
• You already operate, or have firmly committed to, an Apache Druid cluster. The integration is worthless without the backing datastore.
• You need a thin, synchronous query client — parameterized queries, response hydration, configuration via the container — and not a full ORM-style abstraction, schema management, or ingestion tooling.
• You are comfortable vendoring or forking: pin the code, own the security patching, and accept that upstream maintenance is uncertain.

Look elsewhere when:

• You are on Laravel or framework-agnostic PHP. Use a plain HTTP client (Guzzle, Symfony HttpClient, Laravel's Http facade) against Druid's SQL or native JSON query endpoints. The surface area is small and you will own less opaque code.
• Dependency governance matters. Zero stars, zero dependents, and no visible release cadence are supply-chain and bus-factor red flags. A transitive dependency that nobody else uses gets no community CVE attention.
• You need async, streaming, or high-throughput querying. A bundle wrapper rarely gives you the connection control, backpressure, and timeout tuning that production analytics traffic demands.
• You need vendor support, SLAs, or an audited security posture.
• Your Druid version is recent. Older integration bundles frequently lag on SQL endpoint changes, authentication, and TLS configuration.

How to Pitch It (Stakeholders)

To executives: We have an opportunity to accelerate an analytics feature by reusing an existing open-source connector to our real-time data store instead of writing one. The connector is small and narrow in scope, so the engineering cost avoided is real but bounded — think weeks of integration work, not a platform. The material caveat is stewardship: this component has no measurable community adoption and no evident maintainer activity. I recommend we treat it as a starting reference or a vendored component we own, not as a live third-party dependency we inherit. That framing preserves the speed benefit while keeping the risk contained and reversible.

To engineering: This is a Symfony bundle wrapping a Druid client. Two things to settle before we commit: (1) confirm we are not assuming Laravel compatibility — this is Symfony-only and any Laravel use means porting the service wiring ourselves; (2) confirm the Druid version, auth model, and TLS configuration it supports match our cluster, because stale connectors fail at the transport layer, not the API layer. If either check is shaky, the cheaper path is a direct HTTP client against Druid's SQL endpoint — roughly a day of work — and we keep full ownership. Recommendation: spike it behind an internal interface so the connector is swappable, then decide on evidence rather than on the package's existence.