Question:
How can I use two database connections in Auth0 while sharing the same users having same user_ids between them? I need this for testing purposes, where one connection is for production users and the other for testing users. At the end of the testing the test database connection is delete, does this affect the users sharing both the databases. Is it possible to achieve this? How does Auth0 handle shared users across connections, and what are the best practices for such a setup?
Hello @himashya.fonseka,
Thank you for reaching out to us!
I did some testing on this by exporting the users from one DB using the Create export users job, editing the users data from the json file and then importing the json file to a separate DB. This allowed me to essentially have 2 sets of users, with the same user_id, in the same tenant, but comparing the two profiles of one user, both of them were linked to my first DB when I looked under the Identities field. It was expected for something to break along the line, as the user_id is a defining attribute and it’s not allowed to have multiples.
However, this can be accomplished by using multiple tenants, if this fits your usecase. As long as the application can access both DBs that are on different tenants, it will have access to two sets of users with the same user_id. You will just need to export the users from one DB, setup a second DB on a different tenant and import the users.
You can find more information on our Bulk User Imports documentation.
Thank you!
Gerald
Hi gerald.czifra,
Thank you for the response. Based on your solution, we would need to maintain two tenants—one for the production environment and another solely for smoke testing. This approach would also require modifications to enable switching between tenants.
Instead of pursuing that route, we plan to modify the user_ids of the new user set in the new database and adjust the application to recognize the updated user_ids.
It would have been more efficient if Auth0 allowed user_ids to be unique per database connection rather than across the entire tenant. This limitation complicates the process of maintaining backup database connections and adds unnecessary challenges.