Tobias Hillemanns Blog About

Why Are SQL Statements Not Compiled Into The Binary?

Published

SQL was revolutionary in that it eliminated the standalone database process. But it still contains a whole JIT engine. I rethought that.

This thought occurred to me when I was modelling data: what if the compilation step of our server program compiled all SQL statements into native code? What if the database was just a library or a package (like SQLite) we use in our program that gets optimized for our use cases by the compiler itself?

Well, it needs to be written in the same language as we do. But come on. Rust is a good option. And it seems like this is the right end of the spectrum:

Dynamic Schema/Typesof datae.g. JSON, CSVDatastores withsemi-dynamic schemase.g. SQLite, Postgres,etc.Datastores withfixed formatse.g. file typesSQL / enterprise data solutionsare missing here.

What if the tables in your database would just be arrays of structures in your language (e.g. Rust)? Instead of converting into and from your source languages types, it would just be that type at runtime, eliminating runtime checks, data validation, and error handling.

And, whenever you change schemas, you also need to rebuild your project regardless. Schemas don’t change on the fly (at least, dbs are not optimized for this).

This may lead to worse compile times, since every table (B-Tree) has to be compiled specially. But I could also see this as enormous runtime wins, especially with SIMD and compile-time query optimizations.

I don’t know, what do you think?