At the default page size of 2^12 bytes and default page count limit of 2^30 bytes, a database has to reach 2^42 bytes (over 4 Terabytes) to hit your page limit. Yours is a very unusual application if that limit is a legitimate concern. And both of those defaults can be increased. Your use case, which I can only guess at from your pseudo-code, is most unusual. If the database does get too big for its self-imposed limit, any portion of the query sequence which includes DML, (which I presume it can although your code provides for no parameter substitution), or even DDL, can just fail, doing nothing except to note the failure. I would never have guessed this. And given that such failure is to be accepted, I am still left wondering what "reliably" means. Your case where the temp store reaches a full condition is strange as well. That is either like a plain "disk is full" (if the temp store is on the same filesystem as the database) or it is something you might alleviate for some types of temp store backing devices. Yet you want it treated like the improbable page limited case, with submitted SQL statements having no effect on the database. I think you have presented a question of "How do I make my preconceived solution work?" rather than "How do I solve this problem: ...?" My imagination is too limited to devise an actual, real world use case for which your pseudo-code is a solution. For that reason, I feel unqualified to offer advice or suggestions.