The PR [1] for the removal of Druid has already two approvals (one of them
binding). If there are no objections or further comments in the next 24-48
hours I will move on and merge it.

Best,
Stamatis

[1] https://github.com/apache/hive/pull/6615

On Sat, Jul 18, 2026 at 8:13 AM Shohei Okumiya <[email protected]> wrote:

> 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
>>>>>> >
>>>>>>
>>>>>

Reply via email to