If a single web app is being used by all the different companies, unless you have a very specific need or reason to use separate databases (it doesn t sound like you do), then you should definitely use a single database.

Your application will be responsible for only showing the correct information to the correct authenticated users.

Multiple databases would be a nightmare to maintain. For each new company you d have to create and administer each one. If you make a change to one schema, you ll have to do it to your 14+.

Thousands of users and thousands of apps shouldn t pose a problem at all as long as you re using something that is a real database and not Access or something silly like that.

Multi-tenant

Pluses

• Relatively easy to develop: only change database code in one place.
• Lets you easily create queries which use data for multiple tenants.
• Straightforward to add new tenants: no code needs to change.
• Transforming a multi-tenant to a single-tenant setup is easy, should you need to change your design.

Minuses

• Risk of data leak between tenants if coding is sloppy. Tenant view filters can in some cases be employed to reduce this risk. This method is based on using different database user accounts for different tenants.
• If you break the code, all tenants will be affected.

Single-tenant

Pluses

• If you have very different requirements for different tenants, several different database models can be beneficial. This is the best case for using a single tenant setup.
• If you code sloppily, there s practically no risk of data leak between tenants (tenant A will not be able to access tenant B s data). In addition, if you accidentally destroy the schema of one tenant through a botched update, other tenants will remain unaffected.
• Less SQL code when you don t need to take tenant ID values into account in your queries

Minuses

• Database schemas tend to differentiate with time, often resulting in a nightmare. Using a database compare tool, you can alleviate this problem, but potentially many schemas need to be compared.
• Including data from several databases in one query is typically complex, and often requires prepared statements.
• Developing is hard, since you need to make the same changes to multiple schemas.
• The same database entity can appear in many databases with different ID keys, resulting in confusion.
• Transforming a single-tenant to a multi-tenant setup is very hard, should you need to change your design.

A single database is the relational way. One aspect from this perspective is that databases gather statistics about database usage and make heavy use of this. If you split things up you will be shooting yourself in the foot as the statistics will be fragmented.