If read only, you could make multiple SQL Servers using and sharing DB files as scale out solution as following.
Scaling Out SQL Server 2005: http://msdn.microsoft.com/en-us/library/aa479364.aspx
Scalable Shared Databases
The easiest scaleout solution to implement in SQL Server 2005 is Scalable Shared Databases. You create a database on a SAN, and up to eight SQL Server instances running on different servers attach to the database, and start handling queries. This is the classic "shared disk"–style scaleout solution, where processing power is scaled out, but only a single disk image of the data is used. At this point, those of you who understand SQL Server are saying, "But what happens to the locks? I thought each SQL Server instance kept its own locks in its own memory." This is true. Each instance will maintain its own database locks, and none of the instances will know about the other instances' locks. The only way this will work is if there are no locks, and thus Scalable Shared Databases work only if the database is attached as a Read Only database. This means that Scalable Shared Databases are great for data warehouses or reporting databases, but they are not suitable for applications that update data. Going back to our data characteristics, Scalable Shared Databases work only if the Update Frequency is zero. This data is, by definition, historical, and therefore it is all reference data. Figure 1 illustrates the use of Scalable Shared Databases as a scaleout solution.
For SQL Server Scale Out topics, here is an summary by SQLCAT http://blogs.msdn.com/sqlcat/archive/2008/06/12/sql-server-scale-out.aspx
Hope this helps.
Dannol
