Your runAllTests request is using too many DB resources

A couple of months ago, I have encounter a very strange error when deploying components in Production where Salesforce is throwing an error message saying "Your runAllTests request is using too many DB resources". Digging deeper on the error message, I came upon this knowledge article that mentions of a limit 350,000 of DML rows on all test classes. What's fascinating is that the limit is not in the documentation. From what I understood, the limit is associated with the oracle database rollback used in the backend.

This is really a big issue specially if there are a lot of applications on your instance and you plan to add one. Also, regardless whether you optimise your code to limit data created on test classes, it would be a matter of time before you reach the limit. If your environment is not yet enabled for FAST deploy as discuss in my previous blog post, you will not be able to do regular deployment.

As of right now there is no fool-proof solution for this. However, there are a couple of things I would recommend you check in case you are getting the error message.

1. Check if your environment is loading bulk data from static resource. I'm not a big fan of the Salesforce documentation because some of the information are vague (at least for me) and having to clarify to support how salesforce computes, let's say a limit is so slow and takes weeks to confirm based on my experience. Basically loading data from static resource using Test.loadData are computed as part of this overall DML row limit.
2. Are you using Custom Settings as holder of your environment variables? One of the things I learned from previous Dreamforce sessions is that you can use custom settings as holder of environment variables so that you don't need to maintain static values on a class since its hard to redeploy components in Production environment and using custom labels to do this may not be the best solution (and using custom labels for storing such values are not good since it should be used for multi-lingual content). This is a similar pattern used for Java and even .NET that is handy. However you may want to review this pattern because it will be a liability at the end because of the limit.
3. Consider Multi-Org Setup. I'll be honest, as of right now I haven't implemented this on a client but having said that, having multiple instances definitely means you have separate limits for each of your unrelated applications. If for somehow some of your applications are connected then maybe you can take a look at Salesforce to Salesforce feature. 
4. Use SeeAllData=true. I don't really recommend this since it slows down processing of test classes and it is not a best practice but it can be a temporary workaround specially if you are loading a lot of test records from your test classes regardless if its coming for custom settings or coded in the class.
5. Check with if Managed Package will help. Now this is something I'm not sure will work and you may want to check with Salesforce but from what I understand, managed package has its own limits with unmanaged package. (I would appreciate if someone can confirm if it would work or not.)

I hope you find the list above helpful. Let me know if you encounter the same issue and if you have any thoughts on how to fix the issue. In addition, please vote my idea on removing DML row limit for loading data using static resource.