Apache Druid Community


Most discussion about Druid happens over email and GitHub, but those aren't the only way to interact with the Druid community. We also do chat, meetups, and more. Check out the following resources if you're looking for help, to discuss Druid development, or just stay up to date:

  • User mailing list: druid-user@googlegroups.com for general discussion, questions, and announcements. This is the perfect place to ask for help if you need it!
  • Druid Forum: Ask and answer questions, read and submit tips and tricks, and find links to Apache Druid articles and videos in the Druid Forum (by Imply).
  • Development mailing list: dev@druid.apache.org for discussion about project development.
  • GitHub: Star us at apache/druid and use this to follow Druid development, raise issues, or contribute pull requests. If you're interested in development, please see the Contributing section below for details on our development process.
  • Meetups: Check out Apache Druid on meetup.com for links to regular meetups in cities all over the world.
  • Slack: Many users and committers are present on Apache Druid Slack. Use this link to join and invite others: https://druid.apache.org/community/join-slack
  • Twitter: Follow us on Twitter at @druidio.
  • StackOverflow: While the user mailing list is the primary resource for asking questions, if you prefer StackOverflow, make sure to tag your question with druid or apache-druid.

Getting help

The best place to get a wide variety of help about Druid is via #druid on the Apache Slack team. There is also a druid user google group druid-user@googlegroups.com however slack is the preferred way to get help. You can also report issues and problems, or suggest new features, on GitHub.

Third party companies also provide commercial support and services for Druid, including:


Druid is a community-led project and we are delighted to receive contributions of anything from minor fixes to big new features.

What to work on

If you have an itch to scratch, then by all means do that! Fixing bugs you run into, or adding features you need, are both immensely helpful.

If you're looking for some starter projects, we maintain a list of issues suitable for new developers.

There are plenty of ways to help outside writing Druid code. Code review of pull requests (even if you are not a committer), feature suggestions, reporting bugs, documentation and usability feedback all matter immensely. Another big way to help is through client libraries, which are avaialble in a variety of languages. If you develop a new one, we'll be happy to include it in the list.

Getting your changes accepted

Patches to Druid are done through GitHub pull requests.

Pull requests require one approval (+1) from an established committer on code and text (for documentation) levels. The exception is major architectural changes or API changes, and/or changes to

  • HTTP requests and responses (e. g. a new HTTP endpoint)
  • Interfaces for extensions
  • Server configuration (e. g. altering the behavior of a config property)
  • Emitted metrics
  • Other major changes, judged by the discretion of Druid committers

warrant additional design and compatibility review. Such pull requests require design approvals from three different committers (one of them could also be the author of the pull request). For those, it can help to discuss things on the Druid development list dev@druid.apache.org or a github issue beforehand.

In general please follow the contributing guidelines when sending in pull requests. This will help review proceed as quickly as possible.


All Pull Requests are automatically tested on Travis CI on both AMD64 and ARM64 architectures.


Committers are collectively responsible for Druid's technical management. This involves setting the direction of the project, contributing code, and reviewing code contributed by others.

You don't need to be a committer to contribute- pull requests are welcome from anyone.

Name Organization
Abhishek Agarwal Imply
Alexander Saydakov Verizon Media
Atul Mohan Yahoo
Benedict Jin Alibaba
Charles Allen Snap
Chi Cao Minh Imply
Clint Wylie Imply
David Glasser Apollo GraphQL
David Lim Imply
Daoyue Gao Meituan
Dylan Wylie SpotX
Egor Rashin Rill Data
Eric Tschetter Splunk
Fangjin Yang Imply
Fokko Driesprong GoDataDriven
Frank Chen Shopee
Furkan Kamaci Lagom
Gian Merlino Imply
Himanshu Gupta Splunk
Jihoon Son Imply
Jonathan Wei Imply
Julian Hyde Looker
Jun Rao Confluent
Kaijian Ding Alibaba
Kashif Faraz Imply
Kurt Young Alibaba
Lijin Bin Alibaba
Lucas Capistrant Target
Maggie Brewster Imply
Maxime Beauchemin Preset
Maytas Monsereenusorn Imply
Michael Schiff Adobe
Mingming Qiu Bytedance
Mohamed Slim Bouguerra LinkedIn
Navis Ryu SK Telecom
Niketh Sabbineni Verizon Media
Nishant Bangarwa Rill Data
Parag Jain Rill Data
P. Taylor Goetz EPAM
Roman Leventov Snap
Samarth Jain Netflix
Steve Hetland Imply
Suneet Saldanha Imply
Surekha Saharan Imply
Vadim Ogievetsky Imply
Xavier Léauté Confluent
Xinyu Zhang Qihoo 360
Yue Zhang
Zach Sherman Imply

Becoming a committer

If you'd like to become a committer, that's great! Please contact one of the existing committers for a walk through the process. Basically, what we're looking for is an interest in ongoing contributions to Druid.

General committer guidelines

If you are an official Druid committer then congratulations! You are part of a fantastic group of people. Here are some guidelines to follow to help ensure the Druid project continues to grow and improve:

  1. You can merge your own pull request if it fits the rest of the criteria. A common thing to see is "+1 after travis" from other committers.
  2. A pull request should have at least one +1 from a committer who is not the author, on the "code/textual" level of review.
  3. Pull requests which have just one +1 from a committer couldn't be merged earlier than after 3 working days since PR submission.
  4. A pull request with just one +1 could be merged only by (or in coordination with) the committer who provided the review. Because the reviewer may think that the PR is complex or risky enough that needs another pair of eyes to look at it. If this is the case, the first reviewer should indicate this in the PR approval message.
  5. If a pull request has two or more +1's from committers who are not the author, it could be merged immediately and by any committer. But still, enough time since the PR submission should pass to give folks a reasonable chance to indicate a desire to comment on the pull request. AKA: don't merge a pull request that was submitted Friday evening until at least 1~2 regular work days have passed. Use good judgement here.
  6. Major architectural and backwards incompatible changes, or changes which have long-term maintainance consequences (see examples in the "Getting your changes accepted" section above), should have at least three +1's from committers, on the "design" level of review. One approval could be from the author of the PR. The first committer who indicates that a PR needs design review should add the Design Review tag to such a pull request.
  7. Travis-CI should pass or have some very good reason why it won't pass for a pull request.
  8. You reasonably believe that all comments have been addressed.
  9. You are expected to be the champion for your own pull requests.
  10. Being a champion on a pull request can be a significant undertaking depending on the size of the code change and what parts of the code it touches. It may require communicating with other developers, reconciling differences, organizing community feedback, and/or following up with people who have commented in a pull request to ensure comments have been addressed.
  11. Sometimes code is presented as a work-in-progress or as a point of discussion. Use the WIP or Discuss tags on a pull request in such a case.
  12. If a pull request you are championing is taking longer than expected to merge, be sure to raise the issue in the developer sync.
  13. Limit the number of pull requests you are championing at the same time.
  14. Prioritize code reviews to look at pull requests that are blockers for the next release (see the Milestone marker on the pull request)
  15. Help serve as champion for pull requests that originate from new committers.
  16. If you feel a pull request is required for the next release, mark it as such in the Milestone of the pull request.
  17. Do not comment on a pull request unless you are willing to follow up on the edits.
  18. Give priority to getting older pull requests merged. (Either as their champion or as an active commenter)
  19. And most importantly.. the PMC desires to ensure a positive and effective developer experience! If you find that things are not functioning to your expectations, pleaes raise the issue.

Remember, we all want to see this project thrive!


The PMC (Project Management Committee) is responsible for the administrative aspects of the Druid project. The responsibilities of the PMC include:

  • Approving releases
  • Nominating new committers
  • Maintaining the project's shared resources, including the github account, mailing lists, websites, social media channels, etc.
  • Maintaining guidelines for the project