pg_jitter: Rethinking JIT Compilation for PostgreSQL
PostgreSQL has had JIT compilation since version 11. The idea is straightforward: instead of interpreting expressions row by row at runtime, compile them into native machine code so they run faster. For heavy analytical queries, this can make a real difference.
The problem is that PostgreSQL's built-in JIT relies on LLVM, and LLVM is slow to compile. We're talking tens to hundreds of milliseconds just to produce the compiled code — sometimes even seconds in worst cases. For a short OLTP query that would otherwise finish in a few milliseconds, the compilation overhead alone can be more expensive than running the query itself. In practice, this means most PostgreSQL deployments keep JIT turned off for everyday workloads.
pg_jitter takes a different approach. Instead of using LLVM, it offers three lightweight JIT backends — sljit, AsmJit, and MIR — each generating native code in microseconds rather than milliseconds. That's roughly a thousand times faster at compilation, which changes the equation entirely. JIT becomes practical not just for heavy analytics, but for the kind of queries that make up the bulk of real-world traffic.
Compilation speed
| Backend | Typical compilation time |
|---|---|
| sljit | Tens to low hundreds of μs |
| AsmJit | Hundreds of μs |
| MIR | Hundreds of μs to single ms |
| LLVM (Postgres default) | Tens to hundreds of ms (seconds in worst cases) |
The fastest backend, sljit, consistently delivers 5–25% speedups over the PostgreSQL interpreter across general workloads. AsmJit shines on queries that touch wide rows with many columns. MIR sits in between and covers the broadest set of platforms.
Backend comparison
| sljit | AsmJit | MIR | |
|---|---|---|---|
| Speed | Fastest | Fast (3–5x of sljit) | Fast (15–20x of sljit) |
| Best for | General workloads | Wide rows, deform-heavy | Portability |
| Platforms | arm64, x86_64, s390x, ppc, mips, riscv | arm64, x86_64 | arm64, x86_64, s390x, ppc, mips, riscv |
Some operations see even more dramatic improvements. Text pattern matching (LIKE, ILIKE, regular expressions) can run 2–5x faster, and up to 25x in complex cases — thanks to SIMD acceleration and precompiled patterns. CASE expressions and large IN lists benefit from purpose-built search structures that replace the default linear scans.
Benchmark results
| Benchmark | Workload type | Average speedup |
|---|---|---|
| TPC-C | OLTP | ~8% |
| TPC-H | OLAP | ~6% |
| E-commerce (synthetic) | OLTP | ~14% |
| Analytics (synthetic) | OLAP | ~42% |
| CRM (synthetic) | Text/conditional heavy | ~400% |
pg_jitter is a drop-in replacement — you set a single configuration parameter and PostgreSQL uses the new JIT provider. You can even switch backends at runtime without restarting the server. It supports PostgreSQL 14 through 18, runs on Linux, macOS, FreeBSD, and Windows across ARM64 and x86_64, and carries no LLVM dependency.
The project is currently in beta. It passes all standard PostgreSQL regression tests and over seven million SqlLogicTest cases. If you're running PostgreSQL workloads where JIT could help but LLVM's overhead has kept you away, pg_jitter is worth a look.
pg_jitter is one piece of a larger effort we have underway. If you'd like help getting pg_jitter running in your environment, or are interested in what comes next — get in touch. We're happy to help.