Every website will have different scaling needs. The site may have the need to sustain hundreds or thousands of concurrent users, or it may need to be able to store and index massive amounts of content. It may even have both concerns at the same time.
There is no one magical deployment strategy that is going to deliver out of the box for every occasion. Even if this was possible, would you want to spend the money to afford to be able to handle hundreds of thousands of concurrent users when you really only need to handle a hundred right now?
The Plone CMS has been built by a very smart bunch of developers out there in the Open Source world. Plone has the benefit of building upon the vast experience gained from the Zope application server that it sits on top of and from the ZODB that it uses to store content and data. With very little work, Plone can be deployed for smaller sites, and it can scale out to handle the larger ones too.
What options do you have?
The price tags for either one of these types of deployments can also vary from under $10/month up to pretty much the sky's limit. The new Plone 4 release offers even more performance out of the box than ever before. It is about 50% faster than Plone 3 was overall, and has even more to offer for the organizations that need to store large amounts of content and files. Plone has improved the performance for large files and media by supporting large binary files in a much more efficient way.
Hopefully you will know if you are part of the crowd that is beyond "out of the box" before you get there and have time to plan, load test and stress test your deployment before you take it live. Luckily, Plone has many options that you can utilize when dealing with scaling your CMS.
Scaling Plone Up
There are quite a few areas that Plone will allow you to tune the deployment without having to dive in and rewrite your actual code. Plone can handle caching at many layers in the stack.
Some of these are fairly black box and don't have many knobs for you to tune, such as the ZODB caches, but others, such as the HTTP Proxy Caches, offer many configuration options to help improve the end users' experience. Utilizing the caches in the CMS deployment allows us to scale the application vertically by allocating additional resources to the server that may be running the deployment, and allowing Plone to scale up to use them.
Scaling Plone Out
In even larger deployments and in the cases where you want to handle a high availability situation, you are going to want to be able to scale your deployment horizontally. Luckily the Zope application server supports this very easily and even comes with a clustering service built in. This allows you to take the CMS Deployment stack from above and spread it across many server to distribute the load.
The sky is the limit
This could be taken even further using something like RelStorage and a clustered database running as your ZODB storage. It is even possible to add Memcached to this stack and start leveraging it in your application along with the built-in support from RelStorage. As you can see, the options can keep going from there and we haven't even touched on optimizing the application itself yet.
While it is quite hard to get business managers to share the stats of their websites, it is public knowledge that the FBI and the CIA rely on Plone to manage the content of their large sites. Disney, NASA, eBay, Amazon, Harvard, Stanford and many others all rely on Plone for their online activities. Discover Magazine is getting over a million of unique visitors a month and is powered by Plone. The Rosetta Project used to serve over 80,000 content objects when it was powered by Plone in 2007. The University of Virginia Health System's website is currently running Plone and has served over 1 million unique visitors in a month. Plone.org averages almost 1 million page views per month and Six Feet Up has been hosting it with little issue since 2009.
The bottom line is Plone has been in use on many large deployments and has the real-world road testing that you can depend on.