Well, I'm not sure how helpful my own experience will be, as we have orders of magnitude less data than you, but I'll give it a shot.
One constraint is that you REALLY want ALL of your data to be in RAM at the same time. If QlikView starts swapping to disk, your performance will take such a huge hit as to make it unusable. So then what it probably comes down to is how well you can compress from your source data down into the data models and fields specific to each application, and from there how good QlikView is at compressing what is left. And that's going to be EXTREMELY dependent on your data and your data model.
Let me give what I might consider worst case and best case scenarios based on my own applications.
Worst Case: In perhaps my biggest and most complicated application, I'm reading from a set of custom tables designed to use as little memory as possible and process as quickly as possible in the DBMS itself. Uncompressed, we're probably reading in 2.5 GB of raw data. When loaded in, heavily massaged, compressed by QlikView, and finally presented to the user, it takes about 1 GB of RAM. However, I believe the load process itself peaks at over 2 GB of RAM. Call it 2.5 GB for safety, and we're at that definition of a 32 GB server only handling 32 GB of source data. Also, if you might have 100 users referencing the same file at once, all with different selections, and that 1 GB of RAM suddenly becomes 100 GB of RAM, and your Server needs significantly MORE memory than your source data required to provide reasonable performance. We might say then that your 32 GB server can only handle maybe 800 MB of source data.
Best Case: In another application, we're reading in data from multi-purpose tables shared by multiple systems where no effort has been made to optimize space required. We probably only read half of the rows, a tenth of the columns, and then compress even further when building our own internal data structure in QlikView. For that application, you could say that we're reading in about 32 GB of uncompressed data, but the final application takes only 60 MB of RAM. I happen to know it take significantly more than that during the load, but there would probably be optimizations you could do if RAM was critical. In our case, it wasn't an issue at all, and we burned as much RAM during the load as we wanted while optimizing for load SPEED. So let's assume you could code the load much more efficiently, perhaps using only those same 60 MB of RAM. And let's say you only have one user at a time, or just one user period, such as if you are just throwing up the charts on monitors, and not allowing any interaction. In that case, your 32 GB server would in theory handle over 16 TB of data.
With a spread that covers many orders of magnitude, I frankly have no way to answer your question. It will depend entirely on your data, data structures, how you set things up in QlikView, and so on. My rule of thumb might be, "have enough server RAM to handle your source data", which is to say have a server with terabytes of RAM. That should handle most scenarios, but will of course be vast overkill for others.
You may be able to get a much better answer from someone who's actually had to deal with terabytes of data, of course, but I hate seeing questions left completely unanswered.
