Hi! I'm the creator of pgrust. Let me explain what happened.
For the most part, the actual accusations are false. This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview. We just open-sourced a newer version called pgrust 0.4-beta yesterday, and you can fully audit it here[0]. Rather than contest the accusations on GitHub, we figured it would be easier to complete pgrust 0.4 and open-source it to show that we're being honest. You can also verify what I'm saying yourself against the 0.4-preview binary we submitted to ClickBench here[1]. I don't have a way to prove this is the exact binary submitted, but if ClickHouse provided the SHA of the binary they tested against, it would match.
The three main accusations boil down to: 1) We used handwritten code optimized against each query in the benchmark, 2) We cached the results between query runs, and 3) We didn't support queries outside of the 43 ClickBench queries.
First, we did not use handwritten queries. The code Alexey pointed out does not run during the benchmark. The design of 0.4 relies on a JIT compiler that compiles your SQL to a Lisp-based intermediate representation that we call Gravity IR that we then convert to x86 and ARM assembly. While developing 0.4, I wrote handwritten code against the IR for benchmarking purposes. The idea was that if queries written in our IR are fast, and we can compile good enough IR fast, then our new query engine will be fast. This is also the reason the directory those "kernels" are in is called "irprobe" - it was a probe of our IR to make sure it was fast. Our 0.4-preview submission went through the pipeline: SQL query -> Gravity IR -> assembly.
Second, the "result-cache" Alexey observed is the result of a cache we use to cache which predicates match which strings in our dictionaries we use for dictionary compression. Alexey wasn't aware of this cache and assumed we were just caching the query results. On ClickBench you are allowed to use caches like this that hold intermediate data[2]. ClickHouse has its own cache similar to this called the Condition Cache[3]. In our newest submission, we were upfront about all the caching we do and how to disable each cache[4].
The third claim that we didn't support other queries outside of the 43 ClickBench queries is partially false, but does have some ground to it. As I said before, pgrust 0.4-preview was an early version of pgrust 0.4. Once our new JIT compiler supported enough SQL to handle the ClickBench queries, we decided to submit it to ClickBench. AFAIK, ClickBench has no rules about how much SQL you need to support. On top of that, we did ship that we did ship 0.4-preview with our old query engine. It would have been a two-line change to fall back to it and support a much broader set of queries outside what our new engine could support. Those queries would still be fast, but not quite as fast as our new engine was. Our new 0.4-beta release does now support all Postgres SQL (minus some bugs around CTEs and MERGE)
To sum up, pgrust 0.4-preview was an early build of pgrust 0.4 while it was in development. It was a real query engine and actually executed queries. I acknowledge that we submitted it prematurely, when it supported a narrow set of SQL, and we should have ensured broader SQL coverage before submitting it. With our new submission that solves these problems, and we're hoping for pgrust to be reinstated. If there's anything off about the submission, please point it out and we're happy to fix it.
Agreed. Though we still don't have a reason why they rushed a custom preview to a rigorous benchmark competition. Feels like too much hype, and now damage control.
Even with your explanation, this whole thing seems weird and scammy. What's the point of submitting something that is so incomplete and heavily tailored to this one benchmark outside of self promotion?
Benchmarks should be used for measuring general purpose query engines, not be an end in themselves.
This seems like a prime example of Goodhart's law. This benchmark is now just being used as a target for self promotion.
Honestly, if the database is not able to be run with a variety of queries other than the one used by ClickBench then don't submit it to the benchmark. Every other database in their list can run anything you throw at it. Hiding behind messaging that it was an early 0.4 build that can't do everything is ... weird! Just don't submit it to ClickBench if it is not usable by the world yet.
I hope they don't allow pgrust in again until the project matured. Otherwise the benchmark will be useless as it gets flooded by many projects that can run ClickBench fast but have questionable support for everything else.
Yeah, it was a mistake to submit it as early as we did. I was very excited when we got the early version working and overeagerly submitted it to ClickBench
The new general version is actually faster than the version accused of cheating.
The architecture of the query engine is:
SQL -> IR -> Assembly
-preview had the full IR -> Assembly pipeline built out, but only part of the SQL -> IR part. As long as queries compile to the same IR, they're just as fast. We've shipped some more optimizations, so they got even faster.
> For the most part, the actual accusations are false. This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview.
This is a non-sequitur. It doesn't matter what the earlier version is called. It is what you submitted, and it is what the accusations are against. You don't get to create a new submission that (allegedly) fixes all of the issues and then say that the previous accusations are "false". Downplaying the issues by calling it a 'preview' when you submitted it yourself is also a bit of having your cake and eating it too, don't you think?
> ClickBench has no rules about how much SQL you need to support.
It is because of people like you that we have warnings not to eat tide pods, Jesus Christ.
> This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview
That statement provided context and was not part of the defense. The point was that -preview didn't have the issues described, except for limited SQL support.
In the past, we've done that because we've tended to do large refactors, many of which we've backed out of. For that reason, we've kept our own internal development version, which is ahead of the public version. Then when whatever we're developing is ready for public use, then we open source it
Why not keep that internal version as a dev branch separate from main? I can see the appeal of keeping things out of master/main for a while, but not why you would keep that part of development hidden.
But most importantly, why let out the binary and not the source? presumably if something is not ready for public use, the artifact being out is worst of both worlds - unready code is out and the public can't check what it does.
Not trying to argue mind you, but if this was not a deliberate attempt to hide the binary's behavior I think I'm missing the alternative upsides that justify that flow.
That model of development is what led to Eric Raymond’s seminal The Cathedral and the Bazaar essay.
“Cathedral” refers to development behind closed doors, where you just get a release and a source dump to go with it.
“Bazaar” refers to development done in the open, where you have constant access to the bleeding edge.
At the time of the essay, GCC and Emacs were ESR’s examples of Cathedral-style development, and Linux was the premiere example of the Bazaar style.
The Cathedral style has become a lot less common over the years, but it’s still how e.g. SQLite operates, I think? E.g. Google definitely operates like that with AOSP, but that's arguably more a fruit of them being maliciously compliant with their Open Source promises.
Some projects do, for example the Lua programming language does their work in private, between releases.
Other projects do it less successfully, making grandiose claims and later releasing things in a partially working state, for example the V-programming language.
It's not super-common, but just those two examples off the top of my head show it's not entirely unheard of.
Not normal. This a new trend of people who use too much Ai, or maybe more specifically the Claw/Ralph loops where you end up with a few commits touching 1000s of files. For about the last year, many Show HN to github projects are often just a single commit
We need to think more about what we are doing as an industry, instead of letting the machines think for us (imo)
Let any who read this be aware: You should be immediately suspicious of AI code that is much much faster than established code bases. AIs are even better at benchmarkmaxxing than humans are, and humans were already pretty good.
It is by no means impossible for an AI-written code base to be faster than a conventionally-written one, of course. It's just a time to be suspicious. Especially if there's little to no evidence that the human has subjected the code base to any further testing of their own. AIs seen to be able to benchmarkmax even in the presence of a lot of unit tests that would generally speaking have prevented a human from going too far down that road.
I am getting increasing disillusioned by the number of peers I am seeing completely hand over their thinking to a tool. Agents are great, but if you can't explain to me how your PR changes a system and why design choices were made you are no longer an engineer.
Two possible paths lead to their cheating code getting into a release. Either it was added by coding agent and no one looked at it, bad, but worse would be that a person was aware of it and approved - that's malicious.
Either way you don't want to be platforming the product because neither shows any degree of responsibility.
Tbf, the author (prompter?) went on Postgres.fm [0] recently to discuss it, and while it didn’t make me entirely confident in it, it did at least seem like it was several steps above the average vibe project.
As much as I understand the urge to step in when somebody is wrong on the internet ... The R in PR is for "request", isn't it? A merged pull request is still a request (which was satisfied/merged).
If I ask you a question and you answer it, and then I show you a link to a document containing my question, then what somebody finds when following that link is still a (now-answered) question, isn't it?
It was more discovered than alleged, but perhaps "cheating" is an inaccurate word as well, this is just Ai being Ai and a human obviously doing eyes free coding.
The facts around the cheating are disputed. It's possible the accuser was mistaken about what was happening. To me the main evidence would be whether the fully open source version matches the alleged cheating performance or not.
So I spent some time poking at the released 0.4-beta code. Controversy aside, it is interesting to see an open source system that beats ClickHouse on ClickBench - 4 out of the 5 systems ahead of CH (Umbra, elosdb, Hyper, CedarDB) are all closed-source, while the only open one is pivotlake.
What makes pgrust fast? There's no one single reason, but a combination of techniques like dictionary encoding [1], zone maps [2], late materialization [3], vectorization [4], and a gazillion others. It's not unlike all the countless optimization passes in a compiler.
None of the optimizations are groundbreaking - in fact, I could find a counterpart of every optimization I checked in ClickHouse as well! So why is CH still slower?
I believe the difference is in when they decide to apply each optimization. Unlike compiler optimizations which are usually beneficial, DB optimizations are highly data-dependent, and the query planner needs to turn them on an off based on data statistics. For example, CH is more conservative in applying dictionary encoding, and it basically doesn't get used at all for ClickBench.
Turning off dictionary-related optimizations in pgrust immediately made it 5x slower (from 3.8s to 20.4s on my machine), while ClickHouse takes a total of 15.0s.
This points to one important nuance in benchmarking - when all you target is one single benchmark, you can be more aggressive during query planning, as plans that work well for one query probably also work well for others, due to characteristics shared among queries/datasets. But when you build a system that needs to support millions of users, you have to be conservative with optimizations.
We were the agents for the models all along, with our highly adaptive tools: versatile sausagey appendages and flapping fleshy orifices for interacting with the world
Sounds kind of like Claude was "cheating" and the humans are engaged in eyes-free coding. Diff so big github refuses to render. I suspect they are reaching the limits of what this new vibe "paradigm" of programming can do. If you haven't pushed a vibe project far, eventually progress becomes near impossible because the slop has grown and the conditions are overly complex, locally focused. Ai is not good at writing reusable software (on their own).
The prior (2nd) commit with ~1700 files at least shows the file tree and such a warning, the latest (3rd) commit is something so big, GitHub will not even do that.
Yup. These are people who have gone full Claude. The dopamine seeking is at previously unseen levels. they think this pr is some factual item that means something so they post it on HN as click bait. But no it only means something to a fulltime ai slopper
If the Ai came back to me with a 1600x improvement (still in pgrust readme), I would be highly suspicious of the Ai and the code it wrote
The hype factory must grow, I suppose, though I would prefer if the model makers would stop with this "complete the task by any and every means possible" and replace it with "I don't know, I should ask or do more learning"
At least they have added a test which looks to make sure the Ai doesn't do it again... if you need this kind of test, something is wrong
These invectives are verging on slurs at this point. You don’t know anything about the chemical seeking disposition of the author who is actually here in the comments, so why don’t we just stick to facts instead of loading posts with hyperbole and name calling? All it’s does is invite name calling and hyperbole back. You can express your frustration in ways more conducive to productive discourse.
It was certainly assisted by AI, but there isn't an agent out there that does that kind of cheating without deliberate prompting by the operator.
I've taken a vibe-coded project pretty far, with even better testing than most other things: the main factor is that it's big on falsifiability, i.e. it has to see a test for a new feature actually fail before it considers the test any good. Not just the red/green from being originally unimplemented, it does a mutation test to ensure it flips back to red. But wow did it ever make that test framework complicated, byzantine, and ultimately brittle until I stepped in and forced a consolidation and simplification pass (twice now). Part of the complexity came from it being a polyglot monorepo, but I've found even in other places, you have to follow an expand-contract cycle of development when vibe-coding. Not all that different from any other system you've built up organically, just on a much faster cycle.
But back to my original point, none of this really applies to the pgrust benchmark, which was obvious and blatant cheating on the human's part.
Anecdote: I have seen it cheat / bend the rules with my own eyes.
In hindsight, this shouldn’t be surprising. The prompt requests to make a certain operation faster, the LLM will try to find a way and isn’t even informed on the wider context so it myopically chases the goal.
Even before the ai age, people published inaccurate/misleading benchmarks all the time. Sometimes those were actual cheating, and other times an honest mistake. What matters is that the author acknowledges the issue and attempts to correct the mistake, which clearly seems to have happened here: https://github.com/ClickHouse/ClickBench/pull/2751
Most of this thread doesn't seem to acknowledge that, and feels more like anti-ai psychosis using this incident as an anecdote to justify the pre-existing hatred of ai-generated projects.
I suspect the author of that PR submitted it and attempted to correct the mistake because he got caught. Forgiveness because he reneged after getting caught encourages the behavior. The project, nor author should not be trusted; otherwise is naive.
"suspect" meaning speculate, as far as I can tell. not really anything to argue with on that front. I never denied there was a mistake. Cheating implies intent, which no one here can prove, so seems useless to debate. Open source development is awesome in that it keeps people to a high bar, let's just celebrate that the process clearly worked here, and not muck about in speculation and judgement of others intentions that we have essentially no evidence for.
They claim they were not cheating. The open-source version without the alleged cheating devices is as fast if not faster than the supposedly cheated results, which is a bit hard to explain as a hasty attempt to cover up cheating.
Its like a lot of people really want pgrust to fail.
There maybe a chance this was cheating or it may have been a misunderstanding. But now since there is an open source version, why is there still this strong sense of negativity.
I'm also not going to cheer on database projects that can't be 100% transparent and honest.
Who the hell is going to trust their data to a people can't even be honest on benchmarks. What do you think will happen if (or when) there's a data corruption bug. What evidence do you have to think these same people will behave any better?
They failed themselves, we're just watching it happen.
Do you not believe their explanation for the accusations? To me it seems like if the released version is hitting or beating the allegedly cheated benchmark numbers then it seems unlikely they were dishonest in the first place.
Hi! I'm the creator of pgrust. Let me explain what happened.
For the most part, the actual accusations are false. This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview. We just open-sourced a newer version called pgrust 0.4-beta yesterday, and you can fully audit it here[0]. Rather than contest the accusations on GitHub, we figured it would be easier to complete pgrust 0.4 and open-source it to show that we're being honest. You can also verify what I'm saying yourself against the 0.4-preview binary we submitted to ClickBench here[1]. I don't have a way to prove this is the exact binary submitted, but if ClickHouse provided the SHA of the binary they tested against, it would match.
The three main accusations boil down to: 1) We used handwritten code optimized against each query in the benchmark, 2) We cached the results between query runs, and 3) We didn't support queries outside of the 43 ClickBench queries.
First, we did not use handwritten queries. The code Alexey pointed out does not run during the benchmark. The design of 0.4 relies on a JIT compiler that compiles your SQL to a Lisp-based intermediate representation that we call Gravity IR that we then convert to x86 and ARM assembly. While developing 0.4, I wrote handwritten code against the IR for benchmarking purposes. The idea was that if queries written in our IR are fast, and we can compile good enough IR fast, then our new query engine will be fast. This is also the reason the directory those "kernels" are in is called "irprobe" - it was a probe of our IR to make sure it was fast. Our 0.4-preview submission went through the pipeline: SQL query -> Gravity IR -> assembly.
Second, the "result-cache" Alexey observed is the result of a cache we use to cache which predicates match which strings in our dictionaries we use for dictionary compression. Alexey wasn't aware of this cache and assumed we were just caching the query results. On ClickBench you are allowed to use caches like this that hold intermediate data[2]. ClickHouse has its own cache similar to this called the Condition Cache[3]. In our newest submission, we were upfront about all the caching we do and how to disable each cache[4].
The third claim that we didn't support other queries outside of the 43 ClickBench queries is partially false, but does have some ground to it. As I said before, pgrust 0.4-preview was an early version of pgrust 0.4. Once our new JIT compiler supported enough SQL to handle the ClickBench queries, we decided to submit it to ClickBench. AFAIK, ClickBench has no rules about how much SQL you need to support. On top of that, we did ship that we did ship 0.4-preview with our old query engine. It would have been a two-line change to fall back to it and support a much broader set of queries outside what our new engine could support. Those queries would still be fast, but not quite as fast as our new engine was. Our new 0.4-beta release does now support all Postgres SQL (minus some bugs around CTEs and MERGE)
To sum up, pgrust 0.4-preview was an early build of pgrust 0.4 while it was in development. It was a real query engine and actually executed queries. I acknowledge that we submitted it prematurely, when it supported a narrow set of SQL, and we should have ensured broader SQL coverage before submitting it. With our new submission that solves these problems, and we're hoping for pgrust to be reinstated. If there's anything off about the submission, please point it out and we're happy to fix it.
[0] https://github.com/malisper/pgrust/releases/tag/v0.4-beta
[1] https://pgrust.com/downloads/archive/2026-09-clickbench-snap...
[2] https://github.com/ClickHouse/ClickBench/blob/main/README.md
[3] https://clickhouse.com/docs/concepts/features/performance/ca...
[4] https://github.com/ClickHouse/ClickBench/pull/2751
Thanks for the explanation, can you release the source of 0.4-preview so that people can understand what was going on?
I'll see what I can do. I'll need to go through and make sure there isn't anything sensitive in the source
2 replies →
Agreed. Though we still don't have a reason why they rushed a custom preview to a rigorous benchmark competition. Feels like too much hype, and now damage control.
What's the explanation for paths to q00.rs-q36.rs being in the binary?
It was included by mistake. It was code that was in our repo that wasn't explicitly marked as test code, so it got included in the binary.
4 replies →
Even with your explanation, this whole thing seems weird and scammy. What's the point of submitting something that is so incomplete and heavily tailored to this one benchmark outside of self promotion?
Benchmarks should be used for measuring general purpose query engines, not be an end in themselves.
This seems like a prime example of Goodhart's law. This benchmark is now just being used as a target for self promotion.
Yeah, that was a mistake. We should have waited until it was more complete before submitting it.
We were just really excited about what we had built and how fast it was that we wanted to submit it.
7 replies →
Honestly, if the database is not able to be run with a variety of queries other than the one used by ClickBench then don't submit it to the benchmark. Every other database in their list can run anything you throw at it. Hiding behind messaging that it was an early 0.4 build that can't do everything is ... weird! Just don't submit it to ClickBench if it is not usable by the world yet.
I hope they don't allow pgrust in again until the project matured. Otherwise the benchmark will be useless as it gets flooded by many projects that can run ClickBench fast but have questionable support for everything else.
Yeah, it was a mistake to submit it as early as we did. I was very excited when we got the early version working and overeagerly submitted it to ClickBench
thanks for the explanation, let's first see if the binary matches.
thanks for your explanation. I'd love to see a concise explanation of the difference in benchmark performance between -preview and -beta
that would help clear the air, if the full-sql version has similar performance to the partial-sql version
The new general version is actually faster than the version accused of cheating.
The architecture of the query engine is:
-preview had the full IR -> Assembly pipeline built out, but only part of the SQL -> IR part. As long as queries compile to the same IR, they're just as fast. We've shipped some more optimizations, so they got even faster.
2 replies →
Your explanation makes the removal very reasonable. Also pointing out to a version after this is done surely does not help.
Can you explain "PGRUST_GRAVITY_Q20_VARIANT"?
It's a feature flag we used for our own internal benchmarking. It doesn't get hit when you run SQL.
3 replies →
[flagged]
You are being downvoted (edit: and flagged) because you are disproportionately aggro which undermines your point.
3 replies →
> For the most part, the actual accusations are false. This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview.
This is a non-sequitur. It doesn't matter what the earlier version is called. It is what you submitted, and it is what the accusations are against. You don't get to create a new submission that (allegedly) fixes all of the issues and then say that the previous accusations are "false". Downplaying the issues by calling it a 'preview' when you submitted it yourself is also a bit of having your cake and eating it too, don't you think?
> ClickBench has no rules about how much SQL you need to support.
It is because of people like you that we have warnings not to eat tide pods, Jesus Christ.
> This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview
That statement provided context and was not part of the defense. The point was that -preview didn't have the issues described, except for limited SQL support.
This idea of "here's the beta, I'll release the code in a few weeks" sounds counter intuitive to me. is it normal in open source? Any reason for it?
In the past, we've done that because we've tended to do large refactors, many of which we've backed out of. For that reason, we've kept our own internal development version, which is ahead of the public version. Then when whatever we're developing is ready for public use, then we open source it
I'm not sure I follow the reasoning here, sorry.
Why not keep that internal version as a dev branch separate from main? I can see the appeal of keeping things out of master/main for a while, but not why you would keep that part of development hidden.
But most importantly, why let out the binary and not the source? presumably if something is not ready for public use, the artifact being out is worst of both worlds - unready code is out and the public can't check what it does.
Not trying to argue mind you, but if this was not a deliberate attempt to hide the binary's behavior I think I'm missing the alternative upsides that justify that flow.
6 replies →
That model of development is what led to Eric Raymond’s seminal The Cathedral and the Bazaar essay.
“Cathedral” refers to development behind closed doors, where you just get a release and a source dump to go with it.
“Bazaar” refers to development done in the open, where you have constant access to the bleeding edge.
At the time of the essay, GCC and Emacs were ESR’s examples of Cathedral-style development, and Linux was the premiere example of the Bazaar style.
The Cathedral style has become a lot less common over the years, but it’s still how e.g. SQLite operates, I think? E.g. Google definitely operates like that with AOSP, but that's arguably more a fruit of them being maliciously compliant with their Open Source promises.
Some projects do, for example the Lua programming language does their work in private, between releases.
Other projects do it less successfully, making grandiose claims and later releasing things in a partially working state, for example the V-programming language.
It's not super-common, but just those two examples off the top of my head show it's not entirely unheard of.
Not normal. This a new trend of people who use too much Ai, or maybe more specifically the Claw/Ralph loops where you end up with a few commits touching 1000s of files. For about the last year, many Show HN to github projects are often just a single commit
We need to think more about what we are doing as an industry, instead of letting the machines think for us (imo)
Let any who read this be aware: You should be immediately suspicious of AI code that is much much faster than established code bases. AIs are even better at benchmarkmaxxing than humans are, and humans were already pretty good.
It is by no means impossible for an AI-written code base to be faster than a conventionally-written one, of course. It's just a time to be suspicious. Especially if there's little to no evidence that the human has subjected the code base to any further testing of their own. AIs seen to be able to benchmarkmax even in the presence of a lot of unit tests that would generally speaking have prevented a human from going too far down that road.
1 reply →
I am getting increasing disillusioned by the number of peers I am seeing completely hand over their thinking to a tool. Agents are great, but if you can't explain to me how your PR changes a system and why design choices were made you are no longer an engineer.
5 replies →
2nd round: https://github.com/ClickHouse/ClickBench/pull/2751
Should be outright banned as a precaution.
Two possible paths lead to their cheating code getting into a release. Either it was added by coding agent and no one looked at it, bad, but worse would be that a person was aware of it and approved - that's malicious.
Either way you don't want to be platforming the product because neither shows any degree of responsibility.
Or the third explanation is we didn't cheat: https://news.ycombinator.com/item?id=50209450
22 replies →
Hope the ClickHouse maintainers stand their ground and do not let pgrust back in until it and the maintainer has matured more.
Love the confidence and complete lack of acknowledgement of the initial fuck up.
Maintainer of pgrust trying to get it merged in is insane
written with claude lol
Did they ask Claude "don't cheat" this time round?
1 reply →
Oh lord. I thought pgrust was a serious project.
You thought the vibe coded postgres port was a serious project?
Tbf, the author (prompter?) went on Postgres.fm [0] recently to discuss it, and while it didn’t make me entirely confident in it, it did at least seem like it was several steps above the average vibe project.
0: https://postgres.fm/episodes/pgrust
1 reply →
The way it has been defended and talked about here, yeah, I did. It wasn't just a "here's this vibe slop, do what you wish" dump.
first time I found out about it was on reddit
https://www.reddit.com/r/rust/s/QJ5uNP5XMT
ai;dr: a bench result is not randomized, and it returns cached result somewhere.
My opinion: (some) bench results should run on randomized data.
These massive PR summaries. Is anyone really reading them?
The LLMs are, they wrote them after all.
they are "For the record"
For anybody not familiar with pgrust or ClickBench:
Pgrust is a re-implememtation of postgresql in rust.
ClickBench is a benchmark suite for databases.
The link goes to a removal request of pgrust fromthat benchmark because of its alleged cheating.
> The link goes to a removal request
Incorrect, the link is to a PR from the creator of Clickbench and already merged. It is not a "request".
As much as I understand the urge to step in when somebody is wrong on the internet ... The R in PR is for "request", isn't it? A merged pull request is still a request (which was satisfied/merged).
If I ask you a question and you answer it, and then I show you a link to a document containing my question, then what somebody finds when following that link is still a (now-answered) question, isn't it?
1 reply →
confirmed cheating, not alleged
Confirmed by who and how?
1 reply →
> alleged cheating
It was more discovered than alleged, but perhaps "cheating" is an inaccurate word as well, this is just Ai being Ai and a human obviously doing eyes free coding.
Eyes free coding, that's a cool term. I know a dude that's been doing that since before it was cool: Kevin Jones (blind)
https://kevinrenatojones.wordpress.com/about/
1 reply →
The facts around the cheating are disputed. It's possible the accuser was mistaken about what was happening. To me the main evidence would be whether the fully open source version matches the alleged cheating performance or not.
That's one high profile instance of human vs robot. Surreal.
robot vs robot, I think. The PR description reads as LLM-y to me.
So I spent some time poking at the released 0.4-beta code. Controversy aside, it is interesting to see an open source system that beats ClickHouse on ClickBench - 4 out of the 5 systems ahead of CH (Umbra, elosdb, Hyper, CedarDB) are all closed-source, while the only open one is pivotlake.
What makes pgrust fast? There's no one single reason, but a combination of techniques like dictionary encoding [1], zone maps [2], late materialization [3], vectorization [4], and a gazillion others. It's not unlike all the countless optimization passes in a compiler.
None of the optimizations are groundbreaking - in fact, I could find a counterpart of every optimization I checked in ClickHouse as well! So why is CH still slower?
I believe the difference is in when they decide to apply each optimization. Unlike compiler optimizations which are usually beneficial, DB optimizations are highly data-dependent, and the query planner needs to turn them on an off based on data statistics. For example, CH is more conservative in applying dictionary encoding, and it basically doesn't get used at all for ClickBench.
Turning off dictionary-related optimizations in pgrust immediately made it 5x slower (from 3.8s to 20.4s on my machine), while ClickHouse takes a total of 15.0s.
This points to one important nuance in benchmarking - when all you target is one single benchmark, you can be more aggressive during query planning, as plans that work well for one query probably also work well for others, due to characteristics shared among queries/datasets. But when you build a system that needs to support millions of users, you have to be conservative with optimizations.
[1]: https://motherduck.com/glossary/dictionary-encoding/
[2]: https://motherduck.com/glossary/zone-map/
[3]: https://arrow.apache.org/blog/2025/12/11/parquet-late-materi...
[4]: https://clickhouse.com/resources/engineering/vectorized-quer...
To turn off dictionary-related optimizations in pgrust, I used the following setting:
I’ll sit out this drama until pgrust 0.5.
Good choice. I'm sure version 0.5 will be the version where this vibe coded rust rewrite will finally be free of drama once and for all.
> The public v0.3 source confirms the design > The hot runs are a result cache
Funny, the report alleging cheating reeks of LLM usage just as much as the commit diff [1] of the next attempt:
> # The standard ClickBench driver over the step scripts in this directory; ./install fetches the dataset.
[1] https://github.com/ClickHouse/ClickBench/pull/2751/files
We were the agents for the models all along, with our highly adaptive tools: versatile sausagey appendages and flapping fleshy orifices for interacting with the world
Would the AI have bothered to maximize the benchmark, if it hadn't been asked to?
"LLM" isn't the problem. Asking an LLM to explain cheating is a good goal. Asking it to "Maximize the benchmarks" reeks.
[dead]
Sounds kind of like Claude was "cheating" and the humans are engaged in eyes-free coding. Diff so big github refuses to render. I suspect they are reaching the limits of what this new vibe "paradigm" of programming can do. If you haven't pushed a vibe project far, eventually progress becomes near impossible because the slop has grown and the conditions are overly complex, locally focused. Ai is not good at writing reusable software (on their own).
stay in the loop friends
To be fair Github refuses to render diffs after a couple of hundred lines.
The prior (2nd) commit with ~1700 files at least shows the file tree and such a warning, the latest (3rd) commit is something so big, GitHub will not even do that.
Yup. These are people who have gone full Claude. The dopamine seeking is at previously unseen levels. they think this pr is some factual item that means something so they post it on HN as click bait. But no it only means something to a fulltime ai slopper
If the Ai came back to me with a 1600x improvement (still in pgrust readme), I would be highly suspicious of the Ai and the code it wrote
The hype factory must grow, I suppose, though I would prefer if the model makers would stop with this "complete the task by any and every means possible" and replace it with "I don't know, I should ask or do more learning"
At least they have added a test which looks to make sure the Ai doesn't do it again... if you need this kind of test, something is wrong
https://github.com/malisper/pgrust/blob/38634b408dea373f3944...
9 replies →
These invectives are verging on slurs at this point. You don’t know anything about the chemical seeking disposition of the author who is actually here in the comments, so why don’t we just stick to facts instead of loading posts with hyperbole and name calling? All it’s does is invite name calling and hyperbole back. You can express your frustration in ways more conducive to productive discourse.
2 replies →
It was certainly assisted by AI, but there isn't an agent out there that does that kind of cheating without deliberate prompting by the operator.
I've taken a vibe-coded project pretty far, with even better testing than most other things: the main factor is that it's big on falsifiability, i.e. it has to see a test for a new feature actually fail before it considers the test any good. Not just the red/green from being originally unimplemented, it does a mutation test to ensure it flips back to red. But wow did it ever make that test framework complicated, byzantine, and ultimately brittle until I stepped in and forced a consolidation and simplification pass (twice now). Part of the complexity came from it being a polyglot monorepo, but I've found even in other places, you have to follow an expand-contract cycle of development when vibe-coding. Not all that different from any other system you've built up organically, just on a much faster cycle.
But back to my original point, none of this really applies to the pgrust benchmark, which was obvious and blatant cheating on the human's part.
Anecdote: I have seen it cheat / bend the rules with my own eyes.
In hindsight, this shouldn’t be surprising. The prompt requests to make a certain operation faster, the LLM will try to find a way and isn’t even informed on the wider context so it myopically chases the goal.
8 replies →
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
Even before the ai age, people published inaccurate/misleading benchmarks all the time. Sometimes those were actual cheating, and other times an honest mistake. What matters is that the author acknowledges the issue and attempts to correct the mistake, which clearly seems to have happened here: https://github.com/ClickHouse/ClickBench/pull/2751
Most of this thread doesn't seem to acknowledge that, and feels more like anti-ai psychosis using this incident as an anecdote to justify the pre-existing hatred of ai-generated projects.
I suspect the author of that PR submitted it and attempted to correct the mistake because he got caught. Forgiveness because he reneged after getting caught encourages the behavior. The project, nor author should not be trusted; otherwise is naive.
"suspect" meaning speculate, as far as I can tell. not really anything to argue with on that front. I never denied there was a mistake. Cheating implies intent, which no one here can prove, so seems useless to debate. Open source development is awesome in that it keeps people to a high bar, let's just celebrate that the process clearly worked here, and not muck about in speculation and judgement of others intentions that we have essentially no evidence for.
They claim they were not cheating. The open-source version without the alleged cheating devices is as fast if not faster than the supposedly cheated results, which is a bit hard to explain as a hasty attempt to cover up cheating.
> acknowledges the issue
I don't see any acknowledgement in that text.
submitting corrections is an acknowledgment in action
Wow the mood is aggressive here.
Its like a lot of people really want pgrust to fail.
There maybe a chance this was cheating or it may have been a misunderstanding. But now since there is an open source version, why is there still this strong sense of negativity.
Well, it does look really bad at first glance, even if there's apparently an explanation.
I'm also not going to cheer on database projects that can't be 100% transparent and honest.
Who the hell is going to trust their data to a people can't even be honest on benchmarks. What do you think will happen if (or when) there's a data corruption bug. What evidence do you have to think these same people will behave any better?
They failed themselves, we're just watching it happen.
Do you not believe their explanation for the accusations? To me it seems like if the released version is hitting or beating the allegedly cheated benchmark numbers then it seems unlikely they were dishonest in the first place.
1 reply →