Are there downsides to having many SQLite prepared statements at once?

Question

I'm working with some SQLite code in a C++ project that has several hundred prepared statements compiled at once performing operations on a comparable number of tables. All of the statements are simple selects and updates, but the individualized nature of the tables necessitates correspondingly specific SQL, so attempting the reuse of fewer statements for multiple tables is unrealistic. The statements are generally compiled once for the lifetime of the program and finalized on exit. Insofar as concurrency is concerned, at most two or three statements will ever be executed simultaneously on their own threads.

With the number of tables (and therefore, statements) expected to grow continually throughout development, I'd like to be aware of any potential problems with this design before things get any more complex. Having so many statements feels like code smell to me, not to mention a potential debugging nightmare.

I haven't found anything in the docs about prepared statement limits. Are there any practical limits to the number of prepared statements for a single SQLite database connection? Can high numbers of prepared statements cause performance issues?

Answer 1

Prepared statements do not need much memory. While optimizing away the SQL parsing overhead is probably not worth the effort, it will not hurt.