The key question here: what do you mean by "performance degradation" ? Are you interested in execution time or something else ? 1. If you need large-scale testing over different scenarios on a platform, recommendations for testing setups will come from people familiar with the platform, not with SQLite. SQLite is very simple. It reads and writes from storage, and does processing. It knows little about the platform it runs on, and uses little access to operating system facilities. It cannot be used to coordinate cross-platform or cross-scenario testing. My advice is to find people familiar with your platform: hardware, OS, and however your scenarios differ. Ask those people what they'd use for large-scale automated testing of an executable program. Whatever program you're using to call SQLite doesn't matter, it's just an executable, and can be tested like any other executable. 2. How fine do you want your grains ? SQLite is a C API. You can use C, including anything in <time.h> or <ctime>. Or you can use command-line facilities to test the time taken for the entire executable program in whatever shell you're using (e.g. the 'time' command in Linux). Or are you testing for something other than timing ? 3. Overall, SQLite is storage-bound. The processing algorithms are very well tuned. Most of the time taken is in reading or writing to storage, and controlled by cache sizes, latency, and out-of-order writing *on your motherboard* or *in your storage device*, not inside SQLite. You can do a ton of testing with one particular setup, then find your 'fastest compilation options' change because in production the program is running on a later model of hard disk which has a bigger cache, but the manufacturer doesn't advertise the change. Changes in SQLite compiler-time directives may have a small effect. Changes in your hardware may have far greater effects.