Super glaring omission from my side but then again I’ve probably worked no more than 12-15h on my library in total, including research. Still, embarrassing omission for sure. 
This looks like a perfect place to store prepared statements cache, for example. Nice.
Yes, exactly. I want 1ms to be a complete total maximum runtime of all SQL execution functions no matter what. (I don’t mind opening/closing the DB or setting some options to take more than 1ms because those are 0.1% of the function calls.) To that end… 
No problem with that at all indeed. I was just over-fixating on having a synchronous API that might do all sorts of dirty trickery underneath so as to never clog the BEAM VM – having several seconds of response time when querying big SQLite3 public DBs isn’t unheard of. I’ve queried various census databases (1TB+) and there were some simple JOINs with 2-3 filters that took at least 4s. I don’t think any user of the library would mind that at all – but they would mind if the BEAM VM’s guarantees were broken due to it.
So I’ll follow closely the implementation of enif_schedule_nif into Rustler or, depending on timing, might just reach for the guts of SQLite3 and make it periodically yield to internal Rust functions of mine which track progress and assemble the response.
So again, I over-fixated on having a sync API but adding async API has been super tempting from the very beginning! 
I am seeing that Rustler PR not being active for the last PR but right now I don’t have all the necessary Rust qualifications to contribute (sigh).
