In any case you will require a server API (webservice, REST or similar) to connect your Android app to the database. Assuming your database is available through such an API, there are two options.

1. Design the database & server to serve multiple customers (multi-tenancy). With this your server API will expect the tenancy selection to happen on a per-request basis (e.g. a HTTP header or a query attribute), or at session initialization (e.g. when the user logs in).

   REST example:

   # get customers for tenant ABC
   GET example.com/api/customer/?tenant=ABC
   # create a new customer for tenant ABC
   POST example.com/api/customer/?tenant=ABC
   

   Obviously, your server will have to make sure clients can only access data that they are allowed to. Instead of passing the tenant as a query parameter, it can also be passed as an HTTP header or set as part of the session.

2. Create different API endpoints, with each endpoint connecting to a different database. In this case your Android app needs to be configurable in some manner, e.g. by requesting the API endpoint to use from (say) the central login server.

   Example:

   # Request API endpoint to use
   # we assume the configuration response to contain the apiUrl parameter
   apiUrl = GET login.example.com/configuration/?user=XY
   GET <apiUrl>/customer/
   ...
   

   The server will run multiple endpoints, e.g. abc.example.com or xyz.example.com for tenants ABC and XYZ, respectively. So the actual API calls will look like this:

   # get customers for tenant ABC 
   GET abc.example.com/customer
   # get customers for tenant XYZ
   GET xyz.example.com/customer
   

As always with engineering decisions, there are a couple of trade-offs to consider:

1. Data secrecy/segregation v.s. operation efficiency. Multitenancy is relatively simple to solve in a database (add a tenantfield or similar to at least the core tables of your data model, or every table for that matter). Operating one database is easier than operating many. However, in some industries you may need to keep data in separate databases.

2. Declarative v.s. explicit client code. In the first example, your app client needs to be aware of the actual tenant it runs for to be able to send the right parameters to the server. In the second example, all that the app client needs to know is the endpoint’s URL to connect to.

Note that the first and second example could also be mixed:

• In the second example, the same database can be used for different customers. To do so, run a front-end webserver that adds a tenant header to the HTTP request depending on the API endpoint.

• In the first example, the server could route the request to a different database depending on the tenant selection. Some frameworks make such routing trivial, e.g. Django has a database router built-in.