the license of HikariCP is Apache so that would be acceptable

I also noticed the DBCP instructions are somewhat incorrect or at least misleading. https://druid.apache.org/docs/latest/design/metadata-storage/#adding-custom-dbcp-properties

Modifying the defaults by specifying the dbcp properties in the common.runtime.config requires also setting all other parameters specified here https://commons.apache.org/proper/commons-dbcp/configuration

otherwise it will return classpath exceptions/username/password null pointer exceptions, due to missing dbcp parameters

when starting up the coordinator and overlord

Normally I wouldnt expect most users to have to modify the defaults, but this actually becomes a bottleneck when running around 2-3K tasks (real time streaming jobs) in druid, with around 3-4M segments

btw, there was some discussion recently around reducing the # of metadata calls, which would also be useful

this was added in 25.0 to reduce number of calls needed for segment allocation https://github.com/apache/druid/pull/13369

there's also a lot of calls made to

OverlordResource#getTaskStatus

with big shuffle meshes for MSQ tasks (there's actually 2 metadata calls per call to that API -- one for security checks and one for the actual status -- ideally there should be zero in most cases, since it could be read out of memory). i saw some chatter about reducing that but i don't think it's been done yet

i'm not sure if that's an issue with realtime tasks or not

it would be great if it's a choice (dbcp or hikari) so people can opt-in/out in case there is some issue with the new one

that may require creation of new interfaces