Hi, +1 for the removal unless someone is very seriously willing to take on the maintenance role.
Regards, Okumin On Fri, Jul 17, 2026 at 23:51 Stamatis Zampetakis <[email protected]> wrote: > In order to keep the momentum and avoid getting stuck with Druid for the > next 5 years I logged HIVE-29745 [1] and raised a PR [2]. I am hoping that > by next week master will have 30K lines of code less so please take a look > and share your thoughts. > > Best, > Stamatis > > [1] https://issues.apache.org/jira/browse/HIVE-29745 > [2] https://github.com/apache/hive/pull/6615 > > On Fri, Jul 17, 2026 at 3:21 PM Simhadri G <[email protected]> wrote: > >> +1 for removal. >> >> There was already a thread to discuss removing Druid 4 years ago! [1] >> >> There was no response from users using druid back then either. >> >> [1] https://lists.apache.org/thread/1swonwzts4rztz0vdjhllbzmotsdx8ro >> >> >> Thanks! >> Simhadri G >> >> On Fri, Jul 17, 2026 at 5:44 PM Stamatis Zampetakis <[email protected]> >> wrote: >> >>> +1 for immediate removal without deprecation. >>> >>> I checked the state of the Druid module today and it is completely >>> broken. The Druid 0.17.1 version is very old and is incompatible with >>> many of our core dependencies (calcite, avatica, jackson, derby, JDK). To >>> be more precise the module has been broken since at least 2021 where we >>> bumped the jackson version as part of HIVE-24816. At the same time the main >>> end-to-end tests for the module >>> (namely TestMiniDruidCliDriver, TestMiniDruidKafkaCliDriver) have been >>> permanently disabled. >>> >>> To get a sense of how badly broken it is I tried running >>> TestMiniDruidCliDriver >>> with druidmini_test1.q and unsurprisingly failed since Druid's broker, >>> coordinator, historical, cannot come up. I spent a bit of time trying to >>> restore some dependencies (jackson, calcite, avatica, etc.) to be >>> compatible with the old version but eventually hit JDK incompatibilities >>> and abandoned the effort. >>> >>> For the past 5 years, nobody cared or complained about the broken Druid >>> module so I think it's safe to infer that nobody is using it anymore. >>> >>> Best, >>> Stamatis >>> >>> On Thu, Jul 16, 2026 at 8:04 PM Ayush Saxena <[email protected]> wrote: >>> >>>> +1 >>>> >>>> If we conclude that nobody, or almost nobody, is using it, and keeping >>>> it is creating unnecessary resistance to other important initiatives, I’m >>>> fine with removing it in 4.3 as well—although that would be quite an >>>> aggressive move >>>> >>>> -Ayush >>>> >>>> On 16 Jul 2026, at 10:25 PM, Attila Turoczy <[email protected]> >>>> wrote: >>>> >>>> >>>> Totally agree with Sai's points. I also agree to depricate this module. >>>> >>>> -Attila >>>> >>>> On Thu, Jul 16, 2026 at 6:44 PM Sai Hemanth Gantasala < >>>> [email protected]> wrote: >>>> >>>>> Hello team, >>>>> >>>>> I support deprecating druid-handler and targeting removal in a future >>>>> major release. >>>>> >>>>> I worked on HIVE-29707 (upgrade Druid 0.17.1 --> 26.0.0) to address >>>>> CVE exposure from the 2020-era dependency. The handler itself can be made >>>>> to compile, but keeping it current is costly and the blast radius is wide: >>>>> 1) Large API drift across storage handler, indexing, serde, and Kafka >>>>> supervisor classes >>>>> 2) hive-it-druid (~200 MB shaded jar) is pulled into unrelated qfile >>>>> drivers (e.g. TestMiniLlapCliDriver), causing collateral test failures >>>>> 3) Ongoing shading conflicts with Hive's stack >>>>> (Calcite/Jackson/Guava), consistent with the CALCITE-6393 issues mentioned >>>>> above >>>>> Combined with minimal recent development and no clear maintainer/user >>>>> base, I'd deprecate in docs/build now and remove in the next major. I >>>>> wouldn't invest in a full upgrade unless someone commits to long-term >>>>> ownership. >>>>> >>>>> Happy to share HIVE-29707 details if useful for a formal deprecation >>>>> proposal. >>>>> >>>>> On 2026/07/15 11:38:13 Ruben Q L wrote: >>>>> > Hello! >>>>> > >>>>> > In the context of a WIP Calcite upgrade [1] I ran into shading >>>>> issues in >>>>> > druid-handler (an ASM failure when relocating Calcite's >>>>> SqlFunctions.class, >>>>> > tracked upstream in CALCITE-6393). I worked around it by dropping the >>>>> > Calcite relocation in druid-handler/pom.xml, but it prompted me to >>>>> re-open >>>>> > an earlier discussion [2] about whether we should still be carrying >>>>> this >>>>> > module at all. >>>>> > >>>>> > Nothing seems to have changed since it was last raised: we're still >>>>> on >>>>> > Druid 0.17.1 [3] (released in 2020), which has a number of unpatched >>>>> CVEs >>>>> > [4], and there's been essentially no meaningful development in the >>>>> module >>>>> > [5]. >>>>> > >>>>> > So the same questions remain open: >>>>> > - Are there any active users of druid-handler? >>>>> > - If there are users but no maintainers, should we deprecate the >>>>> module >>>>> > (docs + build) and target removal in a future major release? >>>>> > - If there are neither, shall we drop it now? >>>>> > >>>>> > Best, >>>>> > Ruben >>>>> > >>>>> > [1] https://issues.apache.org/jira/browse/HIVE-29641 >>>>> > [2] https://lists.apache.org/thread/1swonwzts4rztz0vdjhllbzmotsdx8ro >>>>> > [3] >>>>> > >>>>> https://github.com/apache/hive/blob/c4791205d84201b351a8353e9eacadbc3c972c3e/pom.xml#L137 >>>>> > [4] https://mvnrepository.com/artifact/org.apache.druid/druid/0.17.1 >>>>> > [5] >>>>> > >>>>> https://github.com/search?q=repo%3Aapache%2Fhive+druid&type=commits&s=committer-date&o=desc >>>>> > >>>>> >>>>
