uplpgsql – PL/pgSQL compiled to native code

uplpgsql compiles PL/pgSQL to native code. It took over twenty years to get here, but here it is.

On July 19, 2005, I demoed my optimizing PL/SQL compiler to Andy Astor, Denis Lussier, and Jim Mlodgenski at EnterpriseDB; PL/SQL packages, procedures, and functions ran on Postgres at native speed, not interpreted. While they didn't acquire it, they brought me on as a founding engineer focused on Oracle Database compatibility and performance.

Then, on November 20, 2014, long after we'd both left, Denis suggested I make it a universal PL compiler that didn't care which dialect it was handed, with front-ends for PL/pgSQL, PL/SQL, SQL/PSM, and T-SQL. "Build it on top of your compiler," he said, "and call it the Universal Procedural Language." I did, but I kept it closed.

uplpgsql is the modern PL/pgSQL version of that compiler, built using AI-assisted analysis and reconstruction of my prior work, now JIT-based and Apache licensed.

Why? Because normal PL/pgSQL is a tree-walking interpreter: every IF, every loop iteration, every assignment costs a switch dispatch and call through exec_stmt. Postgres' built-in JIT doesn't help. uplpgsql compiles the control flow itself to native code through its own LLJIT instance. It has multi-tiered optimizations from truly native to direct Postgres function calls to helpers to an interpreted worst case. Postgres doesn't even need to be built --with-llvm.

Independent benchmarks show 2-4x on ordinary stored procedures and up to 22x on heavy procedural and numerical work. Some functions are currently slower than interpreted; we're working on those regressions.

Super-pre-alpha WIP. Building against PostgreSQL 20devel. Keep it away from anything and everything you care about. It's under heavy development by Joshua Drake (JD) of Command Prompt and me, with several other Postgres companies joining the effort.

Still want to play with it? Build and use LANGUAGE uplpgsql instead of plpgsql. Docker coming soon.