Number 1 is best performance, number 3 is worst. But really, as many other answers have stated - that is the last thing you need to be worried about, specially with the amount of data you posted in your question.
The things I would be worried about:
- Who owns the data and how proprietary is it?
- Are there realistically going to be schema changes and/or different live versions?
- What type of maintenance will you need to do?
- Any inter-client aggregation you need?
- What's the budget here?
- Are there any legal requirements? Can there be in the future?
To expand on each of these:
Who owns the data and how proprietary is it?
If this is your data, then this should not be an issue. However, if this is corporate data of the client, or any kind of personal data, or data that absolutely must not leak - number 3 is out of the question. Unless you waive in some magic to make only a subset of rows unreadable, you're allowing any client to access any other clients data. Your customers might not appreciate this. In fact - if you're a juicy target, then simply execution time or table stats (such as number of rows) already give more information than you may want to expose.
Number 2 is OK, as long as you get your permissions and users right.
Are there realistically going to be schema changes and/or different live versions?
The answer to this question is - of course there are, sooner or later. Unless you just have 1 text field in your DB where you put everything.
There are ways to change the schema gracefully - make sure the new version of the code works with both the old and new schema version, or vice-versa. You will also need to make sure all clients are updated timely. However this also means that you either need to force update the client, or span your schema change across 2 major updates.
How the above relates to your situation? Well, in number 3, you have to synchronize all updates of all clients. That is a nightmare to say the least. Numbers 1 and 2 are easier in this sense, since you can do problematic clients one-by-one without turning them off.
Number 3 is also hell in case one of the clients requests an older version of the app, because the new one doesn't suit them.
What type of maintenance will you need to do?
Backup is the first thing that comes to mind. Here option 3 outshines everything - just dump the table and you're done! Number 2 is OK - a full DB backup is not too difficult. Number 1 is bad - you have to setup a backup on EACH DB. It's incredibly easy to forget or fudge something. However providing a client a backup of their data on request is trivial in 1 and 2, but a bit involved in 3.
How often will you need to change queries to the DB? For number 3 they will be more complicated - or rather - they're as simple, but they have an incredible number of places you can screw up because you forgot the
AND clientId = :clientId.
Any inter-client aggregation you need?
If the case of 1, you better hope you've got a good team of developers and an enterprise server. There is no way to do this that is both easy, reliable and cost-effective.
Number 2 is OK as long as you can generate your queries properly.
Number 3 is easiest.
You'd have to pose the question to your analytics department (if you have one).
What's the budget here?
Lots of DBs may need lots of licenses. And lots of open ports and possibly virtual machines. This depends on what exactly are you using and what hosting is it.
Are there any legal requirements? Can there be in the future?
There are sometimes legal requirements on where data can physically reside. If all your clients are from one country that shouldn't be a problem, but should you go world-wide it may. This is especially applicable to financial and personal data.
A question not mentioned here - are there requirements on latency for the DB? Your Australian or Russian client may not be very happy about their queries going all the way to NY (say).
Another one is resilience and DDoS - physically separated services for separate clients is just that much more difficult to take down.
All in all - I would say if you are using this as a small storage mostly for non-proprietary and non-critical data, and don't expect much growth (as in the amount of data, not company growth) or change in formats - use Number 3. Less hassle, less cost, less admins involved. If this is going to grow into proper datastores with possibly touchy stuff in them - use number 1. Number 2 is somewhere in between.