Database Design – Choosing Between Multiple Databases or a Single Database

Since you don't really need to run this "in" SQL Server and you don't need to reuse any of the code anywhere else in SQL Server, create another server application in the language of your choice and have it triggered by a scheduler. This could give you the option to off-load the number crunching on another server. Using stored procs are still an option if you need it.

You may not have CLR enabled, so why bother just for this?

I think ultimately what you are looking for is an explanation of different ways that SQL Server can be utilized to handle extremely large tables and data sets being replicated across the database server instances. There are multiple approachs to this problem and none of them are a silver bullet, but understanding the basics of each is a good way to make the right architecture choice.

Sharding

Database sharding is a way to take an enormous data set and partition it into a number of different file groups. These individual filegroups can be stored all on a single server, multiple servers, or better yet through a RAID based Storage Area Network.

The bottom line here is that physical IO performance significantly improves when you are accessing records from only a few physical file groups than from an enormous filegroup in an unsharded dataset.

SQL Server does not have a cheap or easy way to do this out of box, nor do I know of any easy or cheap way to do this with other major database providers. Once you start talking about shards then you are playing a different ball game altogether.

Distributed Partition Views

These enable well partitioned datasets to be accessed in such a way that one would only fetch the necessary records based on your partitioning strategy. There is good information on MSDN about this with SQL Server.

Active Clustering

The concept of clustering is to take multiple SQL Server instances as nodes and have them work together on a single database, synchronized so that partitions on different file groups are being read and written to in a way that does not corrupt or damage the data, and in a way that scale up massively.

Peer to Peer Replication

In this setup all database servers have their own instance, and each should be configured to only affect their own little area of the schema. Data is frequently out of date between them and needs to be synced through some outside process and schema changes can be extremely difficult to implement. This is not the ideal way to handle this in your application.

I can't afford distributed partitions and massively scalable active clustering!

So you don't have upwards of a million to drop on some licenses and hardware for massively scalable solutions? There is always the Cloud. Azure and other SQL Server PaaS (Platform as a Service) solution providers can provide you the scalability that you need without the large upfront investment. This is generally the easiest route to go.