Recently I heard someone suggest that RT request tracker may have scalability issues due to its non-normalized database (someone at a Perl meeting I went to referred to it in a positive light as hyper-normalized, but I think he may have misunderstood what normalization is all about). On the other hand I know that large scale enterprises such as Perl's CPAN use RT. Do es this level of scale require special measures to be taken to handle what happens when the db grows too large? What have your experiences been?
SnapOverflow
How busy do you expect a bug tracker to be? My suspicion is that the working set is relatively small, and should be easily cached by the DB.
The only reports of RT scaling problems I can find are from 2003, and only in searching. The main users of RT will probably be email, which should be relatively light compared to random DB search queries.
I worked at a company that had hundreds of thousands of tickets in RT, and before a harsh spam filter was put in place was adding several thousand new tickets a day due to spam alone.
Although being on a box that by today's standards is ancient (P4 class) it never had a peformance issue. That mainly stems from using a properly managed Postgres as the backend, MySQL works fine, but RT is just better optimised for it.
You can tell RT to purge old tickets, but that is destroying data, and a waste of time IMHO.