plX allows you to write safe postgresql procedures in typescript that transpile down to plpgsql. It is open source and licensed under the MIT license.
Release date: 2026-08-18
Previous release: 1.0-alpha (2026-08-04)
pgColumnar is a columnar table access method for PostgreSQL. This is the second
alpha. It adds read-only Apache Iceberg support, reads and writes over
S3-compatible object storage, a maintenance daemon, and a broad round of
statistics, planner, performance, and security work. The on-disk native format
(PGCN v1) is unchanged; existing tables are read and written as before.
This release requires one upgrade command. See "Upgrading" at the end.
s3://, http://, and https:// URLs. Remote access goes through a separate module, is confined to an operator-set endpoint allow-list, and refuses link-local addresses.pgcolumnar.autovacuum daemon performs online upkeep, pgcolumnar.maintenance_due reports what a table needs, and a stripe flush can run across background workers.pgcolumnar.iceberg_scan(metadata_path) reads a table given a column definition list. It resolves each output column to a schema field id, so a data file written before a column rename still reads. It applies position deletes, equality deletes, and format-version-3 deletion vectors (Puffin roaring bitmaps), each under its own sequence and scope rule, and verifies deletion-vector checksums, offsets, and cardinality. A data file with no field ids is bound by the table's schema.name-mapping.default; one with neither field ids nor a name mapping is refused rather than guessed. Only Parquet data files are read. Recorded paths are rebased onto the table's actual location and refused if they resolve outside it. Introspection functions iceberg_current_snapshot, iceberg_data_files, read_avro_manifest, and read_manifest_list are included.pgcolumnar.iceberg_rest_scan(catalog_uri, namespace, table_name) resolves a table through a catalog and reads it with the same projection and delete rules. The first argument may instead name a foreign server of the pgcolumnar_iceberg_catalog wrapper, which holds the catalog URI in server options and the bearer token or OAuth2 client credentials in a user mapping, so one role's secret is private from another and never appears in a function argument or the statement log. When the catalog vends short-lived storage credentials in its load-table reply, the reader uses them for the data files. iceberg_rest_namespaces and iceberg_rest_tables list a catalog.pgcolumnar_iceberg, option metadata_path) receives the query predicate and prunes whole data files before opening them: by partition value for identity, bucket[N], truncate[W], and the temporal transforms, and by stored minimum and maximum for integer and boolean columns. Pruning only removes files that cannot match, so results are unchanged, and EXPLAIN (ANALYZE) reports Files Pruned.s3://, http://, and https:// URLs wherever they accept a local path. s3:// requests are signed with AWS Signature Version 4; https:// verifies the server certificate when the object-store module is built with OpenSSL.pgcolumnar_objstore, loaded on first use, so no second TLS stack enters the main server process by default.pgcolumnar.objstore_allowed_endpoints lists the endpoints remote access may reach. It is empty by default, which refuses every remote endpoint, and it is superuser-only. Link-local and instance-metadata addresses are refused after name resolution.pgcolumnar.autovacuum is a maintenance daemon for the online upkeep that core autovacuum does not perform on a columnar table.pgcolumnar.maintenance_due(rel, compact_due_fraction, recluster_due_fraction) reports whether a table is due for compaction or reclustering.pgcolumnar.parallel_flush dispatches a stripe flush across background workers.pgcolumnar.fsst_verdict_reuse caches a column's FSST keep-or-drop verdict, so a repeated write does not re-run the substring search.pgcolumnar.analyze() now collects most_common_vals and most_common_freqs, places histogram_bounds at PostgreSQL's own positions, honours the per-column statistics target, and counts null_frac over live rows.EXPLAIN (ANALYZE) reports Columnar Usable Skip Predicates beside the skip counters.stripe_row_limit, and the grouped vector aggregate shares the scan node's input-cost estimate, so the planner prices a columnar scan more accurately.col >= $1 from a prepared statement or PL/pgSQL) now drives chunk-group skipping. On a generic plan such a scan previously read every chunk group.delete_vector catalog use its index rather than a sequential scan, so a scan of a table with deletes is no longer proportional to the catalog size.UPDATE or DELETE of the same columnar row serializes on the row identity, so the losing writer gets a retryable serialization failure rather than a lost update.bigint column compared against an unadorned integer literal, now prune chunk groups.CREATE TABLE ... USING pgcolumnar AS SELECT no longer fails when the source is another access method.pgcolumnar.sort_status works for a non-superuser who owns the table.export_parquet and export_arrow no longer leave a partial file.pgcolumnar, and the custom scan node is PgColumnarScan. The native encoding-descriptor wire layout and the delete-vector visibility logic are each single-sourced, with the on-disk format unchanged and verified byte-identical.default_version is 1.0-alpha2. Upgrade scripts from both previously shipped versions (1.0-dev, which the v1.0-alpha tag installed, and 1.0-alpha) ship with the extension, so a single ALTER EXTENSION pgcolumnar UPDATE reaches 1.0-alpha2 from either.Install this build, then run the following in every database that has the
extension:
ALTER EXTENSION pgcolumnar UPDATE;
This is required. The C-symbol rename moves the symbol names each installed
function recorded when it was created; without the catalog update those records
point at symbols the new library does not export, and reading an existing
columnar table fails with could not find function "columnar_handler". No data
is converted and no SQL you write changes. The upgrade replaces catalog entries
only.
See docs/installation.md for the commands, including how to list the databases
that need the update.
pgcolumnar_objstore module built with OpenSSL.We are just going to remove all posts regarding this subject.
It is just clickbait.
I was checking the new FCC ban on foreign inverters and sure enough Victron is going to be hit. We will still be able to get any Victron that has a current FCC id, but in a year, we will all be running outdated hardware compared to other parts of the world.
pgColumnar is a column-oriented storage extension for PostgreSQL, implemented as a table access method. A table created USING pgcolumnar stores its data by column, with per-column compression, chunk-group skipping, and a vectorized aggregate path. It targets analytic workloads: large scans, aggregates, and column projections over append-mostly data.
pgColumnar builds from one source tree on PostgreSQL 15 through 19. It is licensed under the MIT License.
plx is a PostgreSQL extension that lets you write stored functions and triggers
in a Ruby, PHP, JavaScript, or Python dialect. When you run CREATE FUNCTION,
plx transpiles the body to plpgsql and stores that plpgsql in pg_proc.prosrc.
At run time the function is executed by PostgreSQL's own plpgsql interpreter.
There is no separate language runtime loaded into the backend, and nothing new to
run in production.
CREATE FUNCTION grade(score int) RETURNS text LANGUAGE plxruby AS $$
return "A" if score >= 90
return "B" if score >= 80
return "F"
$$;
The front end is dialect-pluggable, and the set of dialects is growing. The dialects available today are:
plxruby: a Ruby dialect. See doc/plxruby.md.plxphp: a PHP dialect. See doc/plxphp.md.plxjs: a JavaScript dialect. See doc/plxjs.md.plxpython3: a Python dialect. See doc/plxpython3.md.Every plpgsql statement type is reachable from every dialect. See
doc/PARITY.md for the construct matrix. The language names carry
a plx prefix, so the extension coexists with the native PL/Ruby and PL/PHP
languages in the same database.
PostgreSQL rewards moving logic into the database: triggers, constraints, set-returning functions, and cursors all run closest to the data. The standard way to write that logic is plpgsql. plpgsql is fast and trusted, but its syntax is unfamiliar to developers who spend their day in Ruby, PHP, JavaScript, or Python, and that unfamiliarity is often enough to keep logic in the application tier where it does not belong.
The usual alternative is an untrusted procedural language such as plpython3u or
plperlu. Those give you a familiar syntax, but at a cost: they load a full
language interpreter into the backend, most are untrusted and therefore
superuser-only, and every row they touch is marshalled across an SPI boundary
into the interpreter's own data structures.
plx takes a different position. A new language surface does not require a new execution engine. plx changes only the syntax you write, not what runs:
pg_proc.prosrc,
where you can read exactly what will run. plx embeds the original source as a
comment so the function is idempotent to re-transpile, but the executable body
is ordinary plpgsql you can inspect, pg_dump, and review.CREATE FUNCTION time, not
per call. At run time there is no translation layer and no per-row marshalling
beyond what plpgsql already does.The goal is to meet developers where they are on syntax without changing what the database actually executes.
Each dialect provides a PlxSurface describing its keywords, block style, comment
syntax, string interpolation, and variable sigil. A shared transpiler lexes the
body, restructures statements, hoists typed DECLAREs, rewrites a fixed set of
operators and interpolations, and passes the remaining expression text through to
plpgsql and SQL unchanged. The call handler is plpgsql's own handler, so execution
is plpgsql. See doc/ARCHITECTURE.md and
doc/TRANSPILER.md.
One function, written in three dialects, each producing the same plpgsql:
CREATE FUNCTION grade(score int) RETURNS text LANGUAGE plxruby AS $$
grade #:: text
if score >= 90
grade = "A"
elsif score >= 80
grade = "B"
else
grade = "F"
end
return grade
$$;
CREATE FUNCTION grade(score int) RETURNS text LANGUAGE plxphp AS $$
if ($score >= 90) { $grade = "A"; }
elseif ($score >= 80) { $grade = "B"; }
else { $grade = "F"; }
return $grade;
$$;
CREATE FUNCTION grade(score int) RETURNS text LANGUAGE plxjs AS $$
let grade = "F";
if (score >= 90) { grade = "A"; }
else if (score >= 80) { grade = "B"; }
else { grade = "F"; }
return grade;
$$;
The stored plpgsql (in pg_proc.prosrc) for each is:
DECLARE
grade text;
BEGIN
IF score >= 90 THEN grade := 'A';
ELSIF score >= 80 THEN grade := 'B';
ELSE grade := 'F';
END IF;
RETURN grade;
END;
Because functions execute as plpgsql, the plx dialects match plpgsql (within about 11 percent across five workloads) and inherit its performance profile: several times faster than the embedded-interpreter PLs on row iteration, and competitive on arithmetic, branching, and call overhead.
All notable changes to Solar Dashboard for Android are documented here. Dates are in YYYY-MM-DD.
First public release. Signed APK attached to the GitHub release.
docs/MANUAL.md.setLegacy(false) and all supported PHYs).solar_dashboard BLE monitor for JBD/Vatrer
BMS batteries and Victron charging/inverting devices.I was inspired by pgEdge's article on why there isn't #TDE (Transparent Data Encryption) for #PostgreSQL. I was curious about this because I knew that Percona had an Open Source TDE extension for our most beloved database.
EDIT: I misread the article. Percona isn't gatekeeping features. Their version just requires their fork of PostgreSQL. This version applies directly to Postgresql.org's version.
It runs on upstream PostgreSQL 16, 17, and 18 (no vendor server fork), keeps the file and KMIP key providers, keeps OpenBao (the Apache-2.0 KV v2 provider) while dropping HashiCorp Vault, and adds pluggable ciphers (AES-128/256-XTS for data files, AES-CTR for WAL) selectable via the open_pg_tde.data_cipher GUC, temporary file encryption, and FIPS enforcement. See the comparison with Percona pg_tde.
This access method:
open_pg_tde core patch (see Installation)tde_heap, with the cipher recorded per tableencrypt_temp_files)PL/Ruby is a procedural-language handler that lets you write database functions in Ruby, stored and executed inside PostgreSQL. You get the expressiveness of Ruby and its standard library with the full power of a native PostgreSQL function: plain functions, set-returning functions, triggers, event triggers, and procedures with transaction control.
PL/php is a procedural-language handler that lets you write database functions in PHP, stored and executed inside PostgreSQL. You get the convenience of PHP's standard library with the full power of a native PostgreSQL function — plain functions, set-returning functions, triggers, event triggers, and procedures with transaction control.
The Open Source Approach: Building Production-Ready AI Apps with Postgres
Multigres: One stop PostgreSQL Management and Scaling
Community, I have been working on a dashboard for my Victron + JBD setup and have reached a point where I would like to share. You can find it here:
https://github.com/ChronicallyJD/solar_dashboard
I would love some feedback. I wanted something dumb simple and it grew from there. It supports:
Victron BMV Victron Inverters Victron MPPT
JBD based batteries.
Runs locally, as a web server, as a TUI and has an API and MCP Server. It can also use SQLLite to store historical data.
It is free and BSD licensed. Enjoy!
Community, I and my bro Claude having been working on an Open Source project to monitor our solar infrastructure. I know a lot of us run Victron and JBD based stuff. If you do, I am looking for your feedback (also considering adding Ecoflow). You can find the project here:
https://github.com/ChronicallyJD/solar_dashboard/
This is what it currently looks like (web and console):
I know there are a lot of options out there for a Solar Dashboard but I wanted something dumb simple that just gave me the information I was looking for with minimal setup. So, over the last 24 hours... I learned how Claude works and built a dashboard. It supports JBD based BMS batteries and Victron.
It is free and Open Source (BSD License).
Running stateful applications can provide many of the same advantages as stateless applications. In this talk, Stephen will share some thoughts on managing stateful applications as part of a CD Pipeline so that applications - and the application's data - can be versioned and deployed safely and repeatedly. This talk will discuss managing structural changes to a PostgreSQL database as part of a CD process. The talk will dive into automation approaches and tooling for managing data migrations between environments and running database schema migrations within a CI/CD pipeline. The talk will feature real-world examples where we discuss specific schema migrations, their possible performance impacts and downtime implications. We will demonstrate how a complex migration can be done with 0 downtime. With AI and CI/CD we can provide something better than before: A more testable, repeatable, and open way to deploy stateful applications. This talk features a practical demo of how CD tooling can empower users to automate data schema migrations within Kubernetes.
