Skip to main content

JIT Compilation

ScramDB runs your SQL by compiling it to native machine code, then executing that code directly on the processor. This is what lets a query written in plain SQL run at speeds closer to a program written and compiled by hand.

Compiled, not interpreted​

Most databases interpret a query: for every row, the engine walks a general-purpose set of instructions that ask, in effect, "what should I do next?" That bookkeeping happens over and over, on every value, and it adds up.

ScramDB instead compiles each query into machine code that is specialized to that exact query: your specific columns, types, filters, and expressions are baked in. The processor then runs a tight, purpose-built routine with the general-purpose overhead removed. The result is more work done per cycle and far less time spent deciding what to do.

Automatic and adaptive​

You do not turn this on or tune it. A query starts executing immediately, and ScramDB compiles its hot, heavily-used parts in the background while results are already flowing. Queries that barely run pay nothing for compilation; queries that do the real work get the full benefit. It is transparent: you write ordinary SQL and ScramDB decides what is worth compiling.

Cached and reused​

Once a query is compiled, ScramDB caches the machine code to disk and reuses it, including across restarts, so the compilation cost is paid once rather than on every run. The cache is tied to a fingerprint of the machine it was built for, so ScramDB only ever reuses code that is valid for the processor it is running on. Move to different hardware and it simply recompiles.

What this means for you​

  • Analytical queries that scan and crunch large amounts of data finish faster.
  • Repeated and dashboard queries are fast from the first run after startup, not just once warmed up.
  • There is nothing to configure, hint, or maintain. The speed is on by default.