I personally receive few report (if any) about performance issues from users of Orthanc.
A user privately reported me in December 2015 that his Orthanc instance contained 3.6TB of data using the built-in SQLite engine. Another user reported 1TB for more than 1,6 millions of DICOM files, also using SQLite.
That being said, the built-in index of Orthanc (that uses SQLite) is not designed to efficiently handle such a large amount of data: “When the size of the content [i.e. the Orthanc index] looks like it might creep into the terabyte range, it would be good to consider a centralized client/server database.” [1] We use SQLite as it is immediate to deploy while providing good performance for small-scale to medium-scale databases.
This is why Orthanc proposes a PostgreSQL plugin, which allows you to replace the lightweight SQLite database of Orthanc by a large-scale, enterprise-ready database system [2]. With the PostgreSQL back-end installed, you should be able to store a virtually unlimited amount of images. Note that you can choose to keep the DICOM files on a standard filesystem (by simply setting the “EnableStorage” configuration option to “false”), in order to avoid any unnecessary load on the PostgreSQL server.
With the PostgreSQL plugin enabled, the performance of the Orthanc core should become independent of the number of stored DICOM files, if the PostgreSQL server is properly scaled (as Chico mentioned). Note that if you use the built-in Web interface Orthanc Explorer, you might find it slow to access the list of the patients. This is because Orthanc Explorer is primarily designed for low-level, administrative purpose [3], and thus does not implement features such as paging. If this is a problem for you, a more advanced Web user interface could be easily developed.
As a conclusion, I would really love to hear about benchmarks of Orthanc. Please share any relevant experience with the Orthanc community.