• Introduction (March 20, 2025)：The SQL evaluation engine in Vitess was originally an AST evaluator but has been replaced with a Virtual Machine. Vitess is designed for horizontal scaling with vtgate handling queries. SQL queries can be complex and need to be evaluated across multiple MySQL instances. The evaluation engine in Vitess supports most scalar expressions but not high-level constructs. It needs to be accurate and fast.
• What's a SQL evaluation engine?：Vitess uses a vtgate to parse SQL and create a shard-aware query plan. Queries are evaluated in one or more shards and results are aggregated. The evaluation engine in Vitess interprets SQL expressions that cannot be evaluated in MySQL. It has been designed to match MySQL's behavior and is comprehensive but needs to be fast.
• The shapes of an interpreter：There are three ways to execute a dynamic language at runtime: AST-based interpreter, bytecode VM, and JIT compiler. SQL expressions are dynamic and high-level, so it is not obvious that a VM will improve performance. However, many programming languages use bytecode VMs and SQL engines can also benefit. The initial approach for Vitess' SQL VM was based on "Efficient Interpretation using Quickening" but was improved by statically typing the SQL AST.
• An efficient Virtual Machine in Go：Implementing a VM is complex and involves writing a compiler and a VM. Traditional bytecode VMs use a big-ass switch statement, which has shortcomings. Go's compiler is not great at optimization, making switch-based VM loops worse. The most interesting approach for interpreters in C or C++ is continuation-style evaluation loops, which can be implemented in Go by using function pointers instead of bytecode. This simplifies the VM and the compiler and improves performance.
• Almost statically typed：Static typing for SQL expressions makes the VM efficient, but SQL has corner cases that can lead to dynamic typing. To work around this, Vitess uses de-optimization, falling back to the AST interpreter when necessary. This allows the interpreter to execute statically typed code without type switches at runtime. However, the AST interpreter cannot be removed from Vitess.
• Conclusion：The new SQL interpreter in Vitess is faster, easier to maintain, and catches up with MySQL's C++ implementation in most cases. It does not allocate memory and benefits from semantic analysis and static typing. JIT compilation is not the next step as the overhead of instruction dispatch is not significant enough.
• Addendum: So why not JIT?：Although a JIT compiler looks like a good idea in theory, in practice, the trade-off between optimization and complexity does not make sense for SQL expressions. Most SQL operations are still high-level and the overhead of instruction dispatch is not large enough to justify a JIT compiler.