What exactly is your use case, what are you hoping to achieve by separating the databases? It will add a whole lot more complexity to your system … so imho you should have a very good reason.
Think about this:
Imagine you have a process with a service task “update customer data”. In a regular camunda setup, completing the service task (move to next element, update history, …) and the changes on you “customer” business entity are written in the same transaction, so if either fails, you have a clean retry. If you use separate datasources, you might as well store to a remote system … you won’t have that guarantee. So every now and then your users will file issues like “data not up to date although I finished the task”, “user task still visible although I see that the latest data was entered” … and you will start a fight against distributed transactions, deal with composition, 2PC, … for what?
I’d like to think dynamic and static business data. My static data (“what is the customers name now”) is stored in custom tables and business entities, my dynamic data ("I have a process running to change that customers name, I am just waiting for some docs) is stored in camundas tables. But they both belong to my domain and I keep them in the same DB.