If the query language is designed with this in mind, the compiler would detect that a non-realtime query is passed to a database marked as realtime and would th

If the query language is designed with this in mind, the compiler would detect that a non-realtime query is passed to a database marked as realtime and would throw an error. Of course the user could issue N realtime queries from within a host language, but that would involve really trying to work against the database. A good analogy might be CORBA/DCOM vs. SOAP. In DCOM days it was easy to call many different functions while being oblivious that each call requires a network roundtrip. Most programmers made this mistake most of the time. With SOAP, you can still work this way, but it makes the likelihood of this happening in practice significantly lower because it exposes the issue to the programmer. Regarding your argument of a fuller optimization, presumably a well designed query language would be flexible enough to allow the user to express every possible realtime query (assuming this is theoretically possible), so the user doesn't need to combine smaller queries via host-language trickery. People have been trying to fix the optimizer for decades, but most production optimizers still have plenty of edge cases. Perhaps redefining the problem is exactly what the doctor ordered?