18+ Procedural Languages Extensions for PostgreSQL

PL/Python, PL/v8, PL/Perl, PL/Rust, and other Postgres extensions for procedural languages — run app logic inside the database. Ranked by GitHub stars.

Last reviewed: May 15, 2026
18 extensions
1
plv8
2.0k+3 30d

PL/JavaScript (v8) trusted procedural language

Procedural Languages·PostgreSQL·C++
2
pgtap
1.1k+7 30d

Unit testing for PostgreSQL

Procedural Languages·PostgreSQL·C
3
plpgsql_check
754+2 30d

extended check for plpgsql functions

Procedural Languages·MIT·C
4
plprql
4730 30d

Use PRQL in PostgreSQL - Pipelined Relational Query Language

Procedural Languages·Apache-2.0·Rust
5
pg_tle
4050 30d

Trusted Language Extensions for PostgreSQL

Procedural Languages·Apache-2.0·C
6
pljava
268+1 30d

PL/Java procedural language

Procedural Languages·BSD-3-Clause·Java
7
plsh
1790 30d

PL/sh procedural language

Procedural Languages·MIT·C
8
pllua
1590 30d

Lua as a procedural language

Procedural Languages·MIT·C
9
plr
1260 30d

load R interpreter and execute R script from within a database

Procedural Languages·GPL-2.0·C
10
plprofiler
1010 30d

server-side support for profiling PL/pgSQL functions

Procedural Languages·Artistic·C
11
pldbgapi
910 30d

server-side support for debugging PL/pgSQL functions

Procedural Languages·Artistic·C
12
dbt2
80 30d

OSDL-DBT-2 test kit

Procedural Languages·Artistic·C
13

Wrapper for the Faker Python library

Procedural Languages·PostgreSQL·Python
14

PL/Perl procedural language

Procedural Languages·PostgreSQL·C
15

PL/PerlU untrusted procedural language

Procedural Languages·PostgreSQL·C
16

PL/pgSQL procedural language

Procedural Languages·PostgreSQL·C
17

PL/Python3U untrusted procedural language

Procedural Languages·PostgreSQL·C
18

PL/Tcl procedural language

Procedural Languages·PostgreSQL·C

What is a PostgreSQL Procedural Language Extension?

Procedural language extensions let you write Postgres stored procedures, functions, and triggers in languages other than PL/pgSQL. PL/Python is the most popular — runs Python directly in the database, useful for ML inference, complex data transformations, and reusing existing Python libraries (NumPy, Pandas, scikit-learn). PL/v8 runs JavaScript via the V8 engine — useful for JSON-heavy workloads and code shared with frontend logic. PL/Rust offers a sandboxed Rust runtime for performance-critical functions. PL/R brings R to the database for statistical computing. PL/Perl and PL/Tcl are older but still maintained for legacy code.

When to Add a Procedural Language Extension

Reach for a PL extension when the business logic is inherently better expressed in another language and the data already lives in Postgres — running a Python ML model row-by-row, generating complex reports with NumPy/Pandas helpers, executing JavaScript-based business rules near the data. Avoid when the logic could live in the application layer — moving compute into the database trades flexibility, observability, and deploy-ability for a small latency win. Avoid PL/Python's untrusted variant (plpython3u) on shared infrastructure — it bypasses Postgres' security model and gives functions unrestricted OS access.

Frequently Asked Questions

What is PL/Python?
PL/Python is a PostgreSQL extension that lets you write functions and stored procedures in Python — directly inside the database engine. Two variants ship: plpython3u (untrusted, full OS access — superuser only) and historically plpython3 (trusted, sandboxed — deprecated since PG 13). You declare a function with CREATE FUNCTION ... LANGUAGE plpython3u AS $$ ... $$;, then call it from SQL like any other function. Common use cases: data cleaning with Pandas, ML inference, calling external libraries that lack Postgres-native equivalents.
What's the difference between PL/pgSQL and PL/Python?
PL/pgSQL is Postgres' native procedural language — SQL with control flow (loops, conditionals, exception handling). Fast, type-safe, integrates naturally with SQL, but limited to what Postgres can express directly. PL/Python lets you write functions in Python — slower (~10-100x for tight loops) but with access to the entire Python ecosystem. Rule of thumb: use PL/pgSQL for business logic that's mostly SQL with some control flow. Use PL/Python when you need libraries (Pandas, NumPy, scikit-learn) or string-processing capabilities SQL lacks.
Can I use JavaScript in Postgres?
Yes — install the plv8 extension (V8-powered JavaScript). It's especially popular for JSON-heavy workloads since V8 handles JSON natively and faster than PL/pgSQL. Common uses: writing JSON transformation functions, sharing validation logic between frontend and database, and complex JSON path operations. plv8 supports modern JS (ES2020+) and can use NPM-style modules with some setup. Supabase ships plv8 enabled by default.
Does PL/Python work on AWS RDS?
Yes — AWS RDS supports plpython3u on PostgreSQL 12+. Enable it by adding plpython3u to the database via CREATE EXTENSION plpython3u; from a superuser-equivalent role. Aurora Postgres supports it similarly. Note that plpython3u is the untrusted variant (the only one available on modern Postgres) and requires superuser privileges to create functions — managed providers handle this by giving you the rds_superuser role. Supabase and Neon also support plpython3u on most plans.
When should I use a stored procedure vs application code?
Use stored procedures when: logic is data-intensive and pushing it into the database avoids round-trips (e.g. complex multi-table updates in one transaction), the logic is enforced as an integrity rule that must run regardless of the caller (triggers, RLS policies), or you need to share logic across multiple application services hitting the same database. Use application code when: logic changes frequently, you want easy version control and CI/CD, you need observability tools and APM integration, or you might switch databases later. Most teams should prefer application code as the default and reach for stored procedures only for the specific cases above.

Manage PostgreSQL Visually

1bench is a modern GUI client for PostgreSQL — install extensions, write queries, and inspect schemas without leaving the IDE.

Try 1bench for PostgreSQL