Hi Nathan,
First thing to clarify is that there is a difference between using the same RabbitMQ/PostgreSQL service and using the same resource within that service (i.e. message queue and database, respectively). Using the same service for multiple users (for example through separate AiiDA profiles) is perfectly safe and recommended.
But I think you are talking about the latter, i.e., whether it is safe to use a single PostgreSQL database (and RabbitMQ queues) for multiple users. This should be possible and stable for most operations, with some caveats.
Imagine that there are 3 physical users that want to share the same AiiDA database. You would have them install the same version of AiiDA on their respective workstations. Then have them create a profile, specifying the connection details to the shared RMQ/PSQL services. They will of course need to specify the same storage plugin. Crucially, their workstations need direct access to the repository. Unless this is an Object Store (enabled through the aiida-s3
plugin for example), it will be a folder on disk, so this would have to be a shared file system for the workstations.
Once that is done, there is one manual step: all profiles need to use the same UUID. So have 1 person look at their aiida.json
config file and note the PROFILE_UUID
of the created profile. The other users need to change their automatically generated PROFILE_UUID
to the same one. The reason this is important is because the RMQ queue names are based on this profile UUID and to make sure they use the same ones, they need to use the same profile UUID.
In principle you should now be set up and the users should see the same data.They should each be able to create data and run processes simultaneously. The reason this works is because multiple users running calculations in the same profile is identical to running a daemon with multiple workers which we do all the time. From AiiDA’s perspective, these things are the same and so it should work.
The one thing that (likely) won’t be shared is the config folder. This means that each user has its own copy of the configuration file, and so, any config settings made by 1 person, won’t be seen by the others. Likewise, all users can run their daemon, but they can only see and manipulate their own daemon as that is running locally on their workstation. Important to note that since the users share the same RMQ queues, it is possible for user 1 to submit a calculation, that is then picked up by the daemon of user 2 if that happens to be running. So the load will be distributed over the daemons. Not sure if that would be a problem. You can even use this fact to have a “worker” server that is the only machine that starts/runs the daemon, and all other workstations are merely submitting calculations/workflows and checking results, and never run the daemon themselves.
Final caveat is that there is a known bug related to node extras where changes to extras can be undone if multiple processes change a nodes extras at the same time. This can also happen in a “normal” AiiDA setup though, so it is not necessarily exclusive to your use case, although it may become more frequent as it is more likely that two people are manipulating the extras of the same node at the same time. See this issue for more background: Possible data loss when multiple threads access the extra of a node · Issue #6628 · aiidateam/aiida-core · GitHub
Hopefully all of this was clear and you can use it to set up a version of it. I recommend you simply start experimenting a bit with some basic example calculations and workflows, and launching/analyzing them from multiple workstations at the same time.