Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- We went this path: pg -> peerdb -> clickhouse replica, then pg -> another pg with pg_clickhouse extension -> clickhouse
This way we keep querying without changing the query language (use same postgres syntax), but switch connection port for analytics query. Experience so far: made 3 PRs to pg_clickhouse (1 merged), otherwise works pretty well.
If something like pgrust would work even better/easier – would definitely check it out instead.
by k_bx - 300x if it is true you will be just busy dealing with you customers rather than pitching here. Also since it is a vibe coded project, if you are really that good , you should even need to related yourself with Postgres. Who will want related itself to something that is 300x slower than itself?
- You use stability of PostgreSQL to open a pitch. Also most people use PostgreSQL because someone out there was a fan, proponent and champion of Postgres. Otherwise they'd be on MySQL or Oracle.
And your sales folks would call and say: "No need to change anything, we still run PostgreSQL, and ours is just called pgrust, but it's N times as fast".
by wkoszek - I'll take the 300x slower non-vibe-coded pg, thanks!by borplk
- They disabled Postgres parallelism to benchmark too. Sigh.by refulgentis
- pgrust seems to have good momentum. AGPL is an odd license for a non web project. Postgres is MIT-like, and that drove it's adoption.
Have pgrust folks reconsidered this? Else, IMO we can have an independant rust port of pgrust, which can be MIT, which will garner more attention.
- Everything around Rust is political, so the license choices are also about political statement.by busterarm
- 2 commits in the repo both generated by claude. This is AI slop, I wonder where you see good momentum?by ognarb
- Good news, we now know up front what an independent port would cost, and it’s not much. So no reason AWS, Google, and friends couldn’t bang out their own port if they want, binary-compatible with this one.
What we don’t know for sure is whether there is any copyright for LLM-generated code. The license might be irrelevant!
by wrs - Oh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water.
It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such a way they’ll never use it?
This also hard blocks upstreaming any beneficial features into core Postgres.
by appplication - Author here. At least for databases, AGPL (or stricter) has become standard. The issue is it's so easy for megacorps (Amazon, Google, etc) to take a permissively licensed product and monetize it at the expense of the original standard.
For instance, Mongo, Cockroach, and Materialize have all gone source available. We picked AGPL because it's the best balance between open source and prevents Amazon from just repackaging it and selling it.
If AGPL is an issue for anyone, we would be happy to dual-license under a commercial license.
by malisper - Surly AI could also write a clearer headline. For the millions running it in production for decades, using a great echosystem of help support, books, consultants, and managed hosting providers; the is a noteworthy difference between the official release and a partially compatable rewrite.by ZiiS
- Batch mode execution has been in Microsoft SQL Server for a while and just recently gained AVX-512 support.
I’ve done some experiments replacing spatial SQL queries with custom vectorised batch mode code in C# and the speed up was astonishing.
The people dubious about these claims have no idea what their computers are really capable of.
by jiggawatts - I don’t understand. It’s not like we don’t already have faster alternatives, don’t we have things like k and kdb that are many orders of magnitude faster even than this?
We use Postgres because it’s fantastic at the scale and problems it solve, if you have an extremely critical system where raw speed is at the core of everything and you’re dealing with petascale then maybe you’re bringing a solution you like to a problem it doesn’t fit?
by hmokiguess - There should be a halfway point between kdb and postgres...
So more seriously my thinking is that we should, on purely moral grounds strive to have things be fast and lean. How many years of human misery have been lost to waiting around for python programs for example because the team for years wanted to the interpreter to be simple
by mhh__ - Faster is better than slower.
Postgres is amazing. When I use Sqlite I miss many of its upsides--better data migrations and better concurrency being two. But queries are not free, and sometimes are slower than I'd like even with the right indexes. And for OLAP-like queries like the one in TFA you might say "well, just don't use postgres for that," but wouldn't it be better if you could? If you could use one database instead of two, or use your favourite database in more places instead of reaching for a different tool?
by repsilat - You have no idea how long I have been waiting for adaptive planning. One of my biggest annoyances with the Postgres core team has been their reluctance to implement any sort of adaptive planning despite it, at this point, being a well-established technique that has been implemented in multiple production databases. I hope this, at the very least, proves the viability of this model outside of academic/niche contexts.by AsyncBanana
- I would be interested about a more detailed architecture overview of the io scheduler (like this: https://www.scylladb.com/2021/04/06/scyllas-new-io-scheduler...) and the thread scheduler.
PostgreSQL has historically been bad at managing the noisy neighbor problem, but with thread pools, and io priorities, it can be solved.
Has this been tackled here ?
by rastignack - I'll need to write up how the scheduler works at some point, but it's heavily based on these papers[0][1]. It solves two different problems. First, it lets us throttle resource-intensive queries. Second, it enables work stealing. If you have idle cores on your machine, we'll assign those cores to running queries to help speed them up. That means if you have an over-provisioned machine, we'll make use of the extra capacity to speed your queries up.
[0] https://15721.courses.cs.cmu.edu/spring2016/papers/p743-leis...
[1] https://db.in.tum.de/~kohn/papers/query-scheduling-sigmod21....
by malisper - Cool project but .. reality is that people will generally not choose pgrust over Postgres, even 5-10 years from now. The problem is not that it may be technically superior and faster by then, it's that it's not built by the trusted Postgres team. There's a lot more to trust than development velocity or performance. It's also about the longevity and continuity of a critical piece of technology.by sgt
- We still have companies that use COBOL and mainframes due to their longevity and continuity. There is no reason Postgres and pgrust cannot both flourish. I can pick and choose which one to use according to its use case.
- The possibility of competition, and an existing proof of concept, could motivate the Postgres team to pursue performance initiatives that they otherwise wouldn't.by NautilusWave
- People are very willing to use new things when something they are using can't do what they want to do.
Dogma is more effective than reliability concerns in my experience. It just happens that the dogma prefers Postgres in this case.
It is just difficult to make these decisions in a more informed way because it requires actual manual testing with the concrete use case and also a decent understanding of databases in question. Chances are you won't have people that understand these things or those people won't have much of a say in decisions.
by ozgrakkurt - I don’t think this is true. There’s plenty of signals for trust - if pgrust keep pouring time, money, and effort into this and get people actually using it even in non critical workloads, it’ll snowball from there. Imagine 2 years from now it’s being used in a couple dozen large companies - people wouldn’t think twice about using it.by mindwok
- Their ai agents will if we keep writing about it
Project managers and Human Resources rolling out overengineered projects will outnumber current software engineers 10 to 1
by yieldcrv - There's also the fact that it's basically vibecoded.by 59nadir
- People will use it if it really delivers gain and can solve problems PG can't.by andriy_koval
- The project has 2 commits.
2.
Commit #1's message is "hey claude, do a breakthrough" from a week ago and is 1.5M lines. Commit #2 is "blog post" from 4 days ago.
My head is spinning. I don't mind AI stuff or AI enabled stuff but there's gotta be some bar for ending up on HN, and also personal accountability: the lack of humility and honesty sets a new low for me. There is no "we" who "released pgrust 0.2". It's one person cosplaying a serious engineering team doing a mountain of work. The bus factor is 1, and its one you can't trust on the basics.
ex. the first 1/3 of the blog post is bloviating about how a rust for loop is faster at summing 500M numbers on the heap than loading the numbers from a table and summing them.
It leaves me in quite some anguish. This site kept me well-informed and growing for 16 years. It is no longer reliable for that as long as things like this can be the #1 post with 60 comments, with the author here, and no one mentioned any of this.
by refulgentis - The second line of commit #2's message is "You can find the actual git history at the v0.2 github tag." which in turn has almost 6000 commits.
I think it's a weird way to handle git history versus squashing feature branches into single commits, but it's not just one Claude session slapped up on GitHub. The OP also has a post above about their exhaustive testing which has uncovered a goodly number of bugs in Postgres itself, too. I think it's fair to say they're putting in a good amount of work on this.
by wffurr - Author here. Let me know if you have any questions about the post or about pgrust.
Let me take a shot at answering what I think will be the most common question: how can I trust pgrust? Our #1 priority right now is correctness. Over the past two weeks, I've done a mix of formal verification and differential fuzz testing. We've been able to prove over 1000 user facing functions have the exact same logic in both pgrust and postgres (see the proofs directory if you're curious). For cases where formal verification is not easy, we've taken the c implementation of a function and the rust implementation of a function and ran millions of inputs through each of them and confirmed they gave the same results every time.
We've only covered about 15% of the surface area so far, but in the process, we've discovered ~100 bugs in pgrust and ~20 bugs in Postgres itself. My favorite postgres bug we found is this one[0]. Postgres has a quadtree implementation. Due to floating point rounding, it was possible for a point to be neither above, nor below, nor even with the center point of the quadtree.
We've also entered engagements with Antithesis[1] to do Jepsen style fault testing and Aretta[2] to do more serious formal verification.
If you want to support the project, the easiest way is to give us a star on GitHub[3]
[0] https://www.postgresql.org/message-id/19597-39c532e61d78dff6...
by malisper