Nile CEO here. Nile provides tenant virtualization. Each tenant has a group of users within them. Typically, you would choose one location for a tenant. This will be based on your customer location. This would mostly stay the same. The users in a company could travel, but the choice of region is usually decided by where the company is located. Yes, you would be able to change the location of a tenant and the data will be moved to a new region but this usually happens if there is a major decision about location in a company.
> This would mostly stay the same. The users in a company could travel, but the choice of region is usually decided by where the company is located.
For most of my apps, I have very little idea on their region aside from their login IP origin, and we get a high level of multi-region travels (like conference organizers). I'd encourage you to transform the notion of a tenant transfers from a 'major decision' to 'assume users will/should switch to closest tenant login'. It looks like your platform already allows this move-tenant-on-login approach, but I'd love to see more docs and more tests around that use-case.
How interesting. Does that mean the same is true for deployment_mode? As in, assuming 'customer 2' was originally made 'dedicated', is this how we'd move them back to shared deployment mode?
update tenants set deployment_mode = 'shared' where name = 'customer 2';
Does that mean some downtime or broken connections for that tenant while data is shuffled around?
