I have been involved with a couple of multi-tenant systems in the past. In some cases, physical separation of data has to exist for legal reasons. In other cases, it is seen as an easier way to ensure data doesn’t accidentally fall into the hands of the wrong tenant.
In the first case, setting up tenants will always be more involved, since physical storage needs to be set up and (db) clients need to be aware of this new storage. As far as I have seen, these cases are relatively rare, and can also be solved using data encryption.
In the latter case, I would recommend storing your events into a single event store, and marking all events with the tenant ID. If all action is always performed by (or on behalf of) a tenant, you could use interceptors to validate this meta data is present/correct on these messages. Some of our clients use this in SaaS based medical application, where security measures are in place to prevent data to be served to the wrong tenant.
My suggestion of using contexts in AxonDB will help you separate the data, but unfortunately, does not help when a single application reads from more than one tenant. Basically, these contexts should be seen as separate databases. They are meant to isolate data from different bounded contexts (as defined by Domain Driven Design). While certain applications should be able to read from multiple contexts at once, this is not designed to be very dynamic.
Hope this helps.