Single DB shared across multiple servers

I've planned to host many servers (50+) each will have more than 20K users stay connected. There is lot of shared data amongst users (e.g. a user needs to refer data prepared by another user).

If I host single database server (preferably Microsoft SQL server), all the (50*20000) queries will be queued to that single server which could be major performance bottleneck. Is it possible to have multiple servers sharing single database. So that it will enable me to distribute my queries across multiple database servers. If this is not possible, what are the options available?

Update: This is completely new game application being developed and I want the design to be highly scalable. As each user's score changes (increases or decreases by certain number) it will be updated to the server. In turn Server will reply with "list of nearest 50 users" to that score. This is planned to happen in not less than 1 minute per user.

Thus if DB table is indexed on score, we can say single write and 50 reads will happen per minute by each user. Now if 20K users are connected to each "connection server" and all those "connection servers" in turn querying single DB Server, it is effectively queuing all the million requests to single DB Server. Which obviously cannot complete all those requests in a minute.

Hence, I was looking if we can distribute those queries across multiple SQL servers which share single database.

No, you can't have the same data from a single database shared across multiple servers, at least not in read/write mode. At the risk of ignoring that you might be prematurely optimizing here, there are some pretty common ways to scale SQL Server, but they aren't all as simple as you might expect, and they also might not meet all of your requirements (or budget, since for many of the options Enterprise Edition is required).

READ/WRITE

For read-write scaling you can "shard" data using federated servers and distributed partitioned views. But note that is not easy to set up. Another options is merge replication but it can also be a bear to set up and maintain.

READ ONLY

You can scale out reads only to multiple other servers by using Log Shipping (or simple backup / restore), transactional replication, Database Mirroring (though this feature is deprecated, so be careful about long-term projects) and Database Snapshots of the mirror, or in SQL Server 2012, AlwaysOn Availability Groups with readable secondaries. (Some good but admittedly biased comparisons with competing vendor solutions here.)

As an aside, I really don't like the term "active secondaries" as that implies to me that you can read/write to them, which you can't.

EDIT

Given the new requirements in the updated question, it seems the part that needs to scale is almost entirely read. One suggestion might be to have a small instance on each application server (could be Express so long as its resource limitations - most importantly 10GB data file - are sufficient). This instance would serve two main purposes: (1) queue updates to the primary server so that the application doesn't have to wait for them (and so that multiple updates from different users can be combined) and (2) serve as a data store for the read-only information so that this doesn't always have to ve retrieved from the primary server. With this idea there isn't really a simple "turn it on" feature that will help accomplish this, but the setup is pretty trivial in the grand scheme of things.

StackExchange Database Administrators Q#33233, answer score: 6