Multiple Tenants having Separate Databases

@TharidhiP

Data is stored based on the Tenant.
CompanyID is the column in Database which indicates the Tenant ID.
 

Thank you for your feedback!

Just supplementing good comments already made...

TABLES / COMPANYID

It is worth mentioning that not all tables have to include a CompanyID, although they almost always do.  If a table does not have a CompanyID, the data will be shared globally as there will be no CompanyID or CompanyMask to isolate the data or control how the data is shared.  This can be an asset or liability to customizations, so serious consideration is required when choosing to exclude this field and bypass the intended data isolation by tenant in the standard Acumatica design.

An example of this is SM.Version.  The DAC provides access to the Acumatica Version, but there is no CompanyID field in the database so the data can be seen by any tenant.

DEVELOPMENT

You reference sandbox for development and concerns about licensing.  If you ran both production and development on the same instance to share a license, customization projects by default drop DLL’s into the bin folder of the instance (shared by all tenants).  You run the risk of a developer overwriting tested production-ready code with a buggy development DLL.  Clearly, this would be bad!

You ALWAYS should do your development on an instance isolated from production, which means a different instance (and by extension a different tenant).  I’ve created endless loops a few times, and you do NOT want that hitting your production server.  I also prefer to keep my development database isolated from production. This allows for a simple rebuild of development if I start making a lot of database schema changes and decide I don’t like them.  We have instances for Dev, QA (where our sys admin works on permissions, business events, etc.) and Test (for our testing and documentation as well as pre-rollout training.)  The non-production instances share a database instance, but separate databases.  I’ve accidentally been in the wrong database more than once when manually cleaning out development tables and fields.  Likewise, you don’t want every developer to have direct access to production data as some of it may be sensitive according to the user’s position with the company, and a developer could query it for all sorts of info that is none of his/her business.  Just be mindful that a snapshot of production will contain all that data, so you must decide if you want the development instance(s) populated with all that data for a developer to snoop around.

The unlicensed install gives 2 concurrent users, so developers can work in their own development instances and use tools like GitHub to check-out code for changes or just merge their work manually with that of other developers.  In my case, we have our development instance running on a separate server, and I connect a drive letter to access the code but compile with visual studio on my PC.  This keeps me out of production data and significantly reduces my ability to affect the production environment accidentally.  I don’t share my development instance with anyone, so this simple approach works for me and ensures the production environment stays backed up even if I take my tablet home at night.