Jeff,

these questions are incredibly hard to answer. I can just give you some hints on how to read the sizing documents and some hints about deployments I have seen.

It is almost impossible, from my perspective, to give good answers without being held liable for it, because the usage models can be completely different.

• If you use only work items, the database will grow only slowly. Unless you upload many huge attachments.
• If you use SCM the database will grow a bit faster, but still moderate. Unless you version huge binaries all the time or upload 20 years of source code history at the start.
• If you upload DVD size movie pictures to your requirements or test results, the same.
• 1000 developers that code and 1000 others that just write defects and browse plans have completely different profiles.
  

When is a database becoming big? That depends on the DB backend and how its architecture/storage is designed.

The performance obsessed people that write the sizing and performance documents and the information here: https://jazz.net/wiki/bin/view/Deployment/PerformanceWhereToStart often talk about concurrent users. Concurrent users is the number of users actively working on the server at the same time. For a given number of N users the number of concurrent users will likely be significantly smaller. Especially if the users are in different time zones.

On Jazz.net we have several 10ths of thousands registered users. However, the amount of concurrent users, I guess, is likely more in the area of some 100 users.

You should plan for an enterprise topology as described in the info center and the deployment Wiki. At the very least you should be able to grow to multiple machines by setting up a reverse proxy in the beginning. You should also talk to your IBM contacts, about sizing. Especially if your deployment is going to be in the region of thousands of users on one system.

If you have existing systems, what is their data? This can be a good indicator for what you can expect.

Today, there are only very limited capabilities available that can help you with outgrowing a server. It is in general hard (or impossible) to move data and projects with history and the like. You don't want to outgrow your deployment.
If the deployment is huge, consider splitting up the deployment into several CLM instances from the start. For example departmentalize. https://jazz.net/wiki/bin/view/Deployment/PlanForMultipleJazzAppInstances tries to give some hints on what to expect.