LUluu·Apr 25, 2026Submission
Pgrx: Build Postgres Extensions with Rust
203 points · Open discussionpgcentralfoundation
pgrx
Rust2020–2026
pgcentralfoundation / pgrx
pgrx
Build Postgres Extensions with Rust!
26Distinct people
36Mentions
1Explicit recommenders
4.8KGitHub stars
What to know before exploring
What it is
Build Postgres Extensions with Rust!
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I love sqlite and rust extension which author has given gets me excited. Last week saw a similar project in rust to built Postgres extensions https://github.com/tcdi/pgx Hope I…
senthilnayagam used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- postgres/postgres · linked in 2 of the same discussions
- supabase/wrappers · linked in 2 of the same discussions
- vadosware/pg_idkit · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year36 dated mentions
Observed mentions: 2020-07-13 14:27:39 UTC to 2026-04-25 08:16:19 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
36 sourcesOn Thursday I learned about ulid[0] which I think really neatly solves the problem of text representation for UUID v7. However, I also like the idea of prefixed ids, although I haven't used them in anger.
Yesterday I built most of a Postgres extension, using the excellent pgrx[1] project, that build on ulid to add prefixes. With it you get something like this
plid=# SELECT gen_plid('u');
gen_plid
---------------------------
u_06DHRQH6SJT7N2WEQK4910R
(1 row)
The aim is for it to be the same size as a UUID in storage, but I haven't quite gotten there yet.
I haven't pushed it to GitHub yet, but it's fairly done at this point.
0: https://github.com/ulid/spec
1: https://github.com/pgcentralfoundation/pgrx
In Ask HN: What Are You Working On? (December 2025)LLMs let me maintain my PostgreSQL extension for PRQL after becoming a parent
Gather around kids, it's storytime. Let me tell you about the time AI saved my open source project from my children.
Once upon a time there was an open source developer who maintained a PostgreSQL extension for PRQL with hundreds of sparkling stars on Github and he had everything his heart desired. But then, a beautiful woman came into his life and offered him her love in return for his devotion. Enchanted by her looks, the developer accepts without hesitation and walks right into it as she reveals the true nature of her gift: two little shits - errh, kids - who will go on to take all his time away from his computer.
Our story began when a critical dependency shipped a breaking change [1] that prevented the extension from supporting PostgreSQL 17. But alas, the maintainer had no time for software engineering. "Fear not girlfriend!", said
Read the rest
the maintainer, "For I will vibe code a fix!". And he summoned Claude Code and touched his keyboard in english places, for he had spent their coin on Claude's Max Plan.
For three nights he labored: The first night brought real progress and the model successfully figured out how to return pgrx::Datum via pgrx::RetAbi. On the second night, the model could not generalize its findings to pgrx::TableIterator and pgrx::SetOfIterator because column types were unknown at compile time. On the third night, the girlfriend said "get your shit together and help me with the kids" and branch pgrx-v0.12.9 [2] faded into obscurity.
As seasons passed and PostgreSQL 18 was released, users grew disillusioned for their sequential transformations of relational data that starts with "FROM" and not with "SELECT" were stuck in PostgreSQL 16. Ashamed of his abandoned repo the developer compartmentalized his failure, for how could he ever learn to maintain open source projects with two small kids?
The answer, as it turned out, was to wait for better models. When Anthropic released Claude Sonnet 4.5, the maintainer tried again. His eyes widened as Claude Code cloned https://github.com/postgres/postgres and inspected PostgreSQL internals exactly as he would have done in a previous life. With the help of WebSearch and a comprehensive test suite that was well understood because it was written before GPT 3.5, the model figured out how to return pg_sys::Datums, SetOf records, and even HeapTuples. By the power of his trust in the tests, the maintainer quickly released v18.0.0 [3] and no longer felt bad about the link on https://prql-lang.org/ that sent thousands of visitors to his repository.
Before our story ends, the maintainer asked the model for certain quality improvements. After a couple of "You are absolutely right!" and spectacular fuckups, he realized some aesthetics must be wrought by human hands. And so he made manual refactorings in commits 82dbc44 [4] and d61d04ad [5], pushed v18.0.1 [6], and lived happily ever after. Who needs time when you have Claude Sonnet 4.5?
[1] https://github.com/pgcentralfoundation/pgrx/pull/1701
[2] https://github.com/kaspermarstal/plprql/compare/main...pgrx-v0.12.9
[3] https://github.com/kaspermarstal/plprql/releases/tag/v18.0.0
[4] https://github.com/kaspermarstal/plprql/commit/82dbc44808871f60d0cc42b65124faf56f3…
[5] https://github.com/kaspermarstal/plprql/commit/d61d04ad735765ef87f4f67d57ecaf0da27…
[6] https://github.com/kaspermarstal/plprql/releases/tag/v18.0.1
Yeah, they would often claim that C API is at fault, but believe it or not, blaming Rust just as much. I've had an interesting discussion with pgrx people: https://github.com/pgcentralfoundation/pgrx/issues/1897#issu... to quote @workingjubilee
> Rust has formally rejected the notion that any function can return twice. Even LLVM has no special knowledge of the name of "sigsetjmp" or "setjmp", only that some functions can return twice.
> Thus, when you call sigsetjmp or setjmp from Rust, Rust doesn't believe that you called a function that can return twice. The Rust compiler refuses to annotate it with the required LLVMIR annotation. Thus LLVM sees a call to sigsetjmp that it believes cannot return twice... it's just an ordinary function that someone named "sigsetjmp" because they have a sense of humor. What LLVM does next is between itsel
Read the rest
f and whatever gods that compilers believe in, and we have no more voice in such a matter.
In this particular case, it's hardly the fault of a "C wrapper."
Glad you like it!
You don't need to recompile it actually! It's enough to compile your extension and Postgres can then dynamically link to it, which makes for a perfectly good feedback loop. pgfdb is built with pgrx: https://github.com/pgcentralfoundation/pgrx, which is a framework for building Postgres extensions in Rust that handles all the compiling and linking for you. Highly recommend that if you want to try writing extensions and are also a fan of Rust!
In Making Postgres Distributed with FoundationDBShow HN: Embed an SQLite database in your PostgreSQL table
pglite-fusion is a PostgreSQL extension that allows you to embed SQLite databases into your PostgreSQL tables by enabling the creation of columns with the `SQLITE` type. This means every row in the table can have an embedded SQLite database.
In addition to the PostgreSQL `SQLITE` type, pglite-fusion provides the `query_sqlite`` function for querying SQLite databases and the `execute_sqlite` function for updating them. Additional functions are listed in the project’s README.
The pglite-fusion extension is written in Rust using the pgrx framework [1].
----
Implementation Details
The PostgreSQL `SQLITE` type is stored as a CBOR-encoded `Vec<u8>`. When a query is made, this `Vec<u8>` is written to a random file in the `/tmp` directory. SQLite then loads the file, performs the query, and returns the result as a table containing a single row wi
Read the rest
th an array of JSON-encoded values.
The `execute_sqlite` function follows a similar process. However, instead of returning query results, it returns the contents of the SQLite file (stored in `/tmp`) as a new `SQLITE` instance.
[1] https://github.com/pgcentralfoundation/pgrx
These days, for writing extensions/FFI pgrx[0] is the best crate.
[0] https://github.com/pgcentralfoundation/pgrx
In Show HN: Pg_replicate – Build Postgres replication applications in RustHe's referencing pgrx:
https://github.com/pgcentralfoundation/pgrx
To be fair pgrx was mentioned in OP under a positive light, and OP did say he likes avoiding coding in C, so it was something to bring up.
In Ask HN: What is the best code base you ever worked on?Postgres. I don't code in C if I can avoid it, since it often feels like an awful lot of extra typing while still having to worry about memory safety. But the Postgres codebase is extraordinarily well organized and respects the humans that work with it with its intelligent handling of memory and judicious use of macros.
I consider the core Postgres codebase to be the gold standard in development even though it's in a language I do not prefer to write in if given the choice.
Shout out to the pgrx folks. You're awesome! https://github.com/pgcentralfoundation/pgrx
In Ask HN: What is the best code base you ever worked on?Yet another amazing postgres plugin made possible by pgrx (https://github.com/pgcentralfoundation/pgrx)
It's really crazy how some projects just instantly enable a whole generation of new possibilities.
If you are impressed like this and want to build something like it -- check out pgrx, it's a pretty great experience.
In Pg_lakehouse: Query Any Data Lake from PostgresConsider also the companies and work behind pgrx [0] and pgzx [1]:
[0] https://github.com/pgcentralfoundation/pgrx
[1] https://github.com/xataio/pgzx
In Building a Managed Postgres Service in RustThere is a separate project to build Postgres extensions with Rust: https://github.com/pgcentralfoundation/pgrx
In Introducing pgzx: create PostgreSQL extensions using ZigIf you like this (I do very much), you might also like pg_idkit[0] which is a little extension with a bunch of other kinds of IDs that you can generate inside PG, thanks to the seriously awesome pgrx[1] and Rust.
[0]: https://github.com/VADOSWARE/pg_idkit
[1]: https://github.com/pgcentralfoundation/pgrx
In UUID v7(disclosure, i work at supabase and have been developing TLEs with the RDS team)
Trusted Language Extensions refer to an extension written in any trusted language. In this case Rust, but it also includes: plpgsql, plv8, etc. See [0]
> PL/Rust is a more performant and more feature-rich alternative to PL/pgSQL
This is only partially true. plpgsql has bindings to low-level Postgres APIs, so in some cases it is just as fast (or faster) than Rust.
> Building a vector index (or any index for that matter) inside Postgres is a more involved process and can not be done via the UDF interface, be it Rust, C or PL/pgSQL
Most PG Rust extensions are written with the excellent pgrx framework [1]. While it doesn't have index bindings right now, I can certainly imagine a future where this is possible[2].
All that said - I think there are a lot of hoops to
Read the rest
jump through right now and I doubt it's worth it for your team. I think you are right to focus on developing a separate C extension
[0] TLE: https://supabase.com/blog/pg-tle
[1] pgrx: https://github.com/pgcentralfoundation/pgrx
[2] https://github.com/pgcentralfoundation/pgrx/issues/190#issue...
I’m currently playing with PostgreSQL, foreign data wrappers, and pgrx rust extensions. My development experience has been surprisingly smooth and enjoyable.
My main issue is that joins will be processed locally, so all the foreign data will be fetched before the join happens. But otherwise basic CRUD is easy.
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
https://github.com/pgcentralfoundation/pgrx
https://github.com/supabase/wrappers
In SQL as APIShowing the 15 most recent of 36 sources. Enable JavaScript to search and browse every indexed mention.