A common question I receive is about how to correctly size a server for an Analysis Services Tabular instance. I always answer that an analytical evaluation is partly an empiric process, because there are many variables involved and the simplest approach is building the database model on a development server and then performing some workload test to understand how much memory and CPU is required. Another rule of thumb is to buy as much memory as you can. But this is not a simple approach if, for example, you want to optimize the size of a virtual machine (considerations about the opportunity to create a virtual machine with hundreds of GB of RAM are material for another post…).
Microsoft published an interesting whitepaper: Hardware Sizing a Tabular Solution in SQL Server Analysis Services. This whitepaper explore in detail the operations required to estimate the required amount of RAM and CPU for a given tabular model. My suggestion is to read the whitepaper carefully, because buying hardware before the development of the solution could be a very bad idea. The best strategy is to allocate a budget at the beginning of the project and to delay the buying of the production server as soon as possible, so hopefully you will get more memory and faster CPUs at the same price. I’d like to quote a statement from the Hardware Configuration Examples that probably many people didn’t believe when pronounced by me at some conference – now that it’s on a Microsoft whitepaper I hope there will be more consensus on this!
Anecdotally, we know that tabular models sometimes perform better on faster, newer processors than on high-end server hardware. Workstations that offer more in terms of raw processor performance are often first to market. When evaluating hardware, broaden your search to include workstations that you might not otherwise consider.
The whitepaper has a lot of practical action to get real numbers and provides you a practical method to get a good estimate. There are also many links to documentation and articles, some of them from this blog and from SQLBI website.