michelp/pgsodium

What it does

It makes the functions of libsodium, a well-regarded encryption library, callable from SQL, which is the language used to query a database. That covers hashing, public-key encryption, digital signatures, deriving keys from other keys, and password hashing. Its key management is the part worth the attention: a root key is loaded into the server at startup and is not readable from SQL, and every other key is derived from it by number, so the database stores key numbers rather than keys. On top of that sits a feature called transparent column encryption, which uses database triggers and views so a column is encrypted on the way in and decrypted on the way out without the application knowing. There is also a section for encrypting network addresses in a way that keeps their structure. Version 3.0.0 needs PostgreSQL 14 or newer, earlier database versions need the 2.0 line, and some of the column-encryption features rely on a PostgreSQL 15 feature. Code was pushed on 10 June 2026. Now the limits, and this project is remarkably honest about them. The managed keys are optional, and without them you have to handle keys yourself. The project says storing secrets in a database is generally a bad idea even though it can be done carefully. It states that a sufficiently capable attacker with full database powers might still reach the root key through other programs, memory dumps or swap files, and that this is outside what the extension can prevent. One of its encryption modes reveals when two stored values are identical. One of its hash functions produces only 64 bits and is not safe against deliberate collisions. And values passed through the standard database client's variables can end up in the database logs.

Why it matters

Who it suits. Anyone who has to encrypt specific fields inside PostgreSQL — a token, a document reference, a national identifier — and wants the key kept out of the database that holds the data. It suits a situation where an auditor is asking where the keys live, because the answer here is concrete. It also suits anyone who cannot change the application, since transparent column encryption works through views and triggers rather than through code changes. Skip it if what you need is encryption of the whole disk or the whole database, which is a different and simpler problem, and skip it if there is nobody on hand who can reason about key rotation.

Verdict. A genuine find at 612 stars, and the reason to read it is the documentation as much as the code: a security project that spends paragraphs on what it cannot protect against has earned the claims it does make. The superuser point is the one to act on, exactly as with the audit extension covered in Edition 57: if one account can reach the running server's memory, no extension inside that server can stop it, so that access is the thing to restrict. Two practical notes. Code was pushed on 10 June 2026, four months before this edition, and the repository publishes no releases, so the version numbers come from the documentation rather than from a tag. And test it on a copy first, because an encryption mistake is discovered later than other mistakes and costs more. For storing a handful of secrets rather than encrypting columns, supabase/vault is the smaller answer; for a layer in front of the database rather than inside it, cossacklabs/acra was covered in Edition 55.