I also love the visualizations but I'm getting heavy LLM vibes from the prose:
> One setting drives this,...
> The cost is now about the rows you actually touch, not rounds times table size.
Etc.
I get the brain scramblies [1] from trying to parse this writing style at work so I hate to see it elsewhere. Apologies if I'm wrong. But if I'm not then OP don't use an LLM to write for you. It's hazardous to your reader's health [2].
> The "does not rescue it". No human would write like that.
This is what I don’t understand. Supposedly LLMs are trained on human text. Why do they come up with such unrealistic prose? Is it intentional because the companies want the tells to be obvious?
They’re not just trained on human prose. They’re sent to RLHF, and also their language changes as a result of RL on verifiable rewards.
Getting it to write well is really hard because there’s no real way to verify whether it’s good prose or not. You and I can tell, but we can’t write a verifier that codifies our judgment.
Maybe they’ll find a way to improve this, but for now it’s certainly one of the harder problems to solve for LLMs.
Part of it is that I think they also have poor theory of mind, which I imagine is also a hard thing to train it to do.
What does the age of the style have to do with anything? You can ask them to write like Dickens or the King James bible or in Caesar's Latin, too, and these are even older.
In fairness, some of those older styles could alienate a reader, whereas mid-20th century style is practically like our own. To emphasize, this is narrowly about applying the style from an era, not the English from an era.
For autoregressive models (practically all hosted ones), it's because of the nature of next-token prediction. LLMs lock themselves into a particular sentence structure ahead of time and have to guess at the rest of the sentence. Samplers have no insight into the LLM's "intent" aside from the probability of each next token, and the LLM has no insight into its previous "intent" that resulted in a given probability in the first place. I don't know if this is possible to solve with more training, I think a fundamental architectural shift may be needed, like more research into diffusion language models.
I think that's quite a strong claim, especially since chain-of-though reasoning means a modern LLM has its own private scratchpad to workshop sentence structure in, if it were a significant problem.
> The "does not rescue it". No human would write like that.
On the contrary. It is unnatural for a native speaker, which I don't think the author is. For someone that speaks English as a second language, it is not uncommon to use expressions literally translated from their first language, which may be understandable but weird for native speakers.
The author does read to me as genuinely ESL, but there is also blatant LLMish mixed in. Perhaps they used LLMs for translation or drafting. For example:
> DuckDB 2.0 is coming this fall and the alpha is out! I ran the interesting features on my own laptop, and against S3, to see what actually changes for people who build tables and pipelines rather than database engines.
The first sentence looks purely ESL, the second one looks LLM.
> Because yes, DuckDB 2.0 is faster. But to get the speed bump you need to understand how your data is shaped, and sometimes how to model it.
The second sentence here looks LLM as well.
> One comment on the tiny files: no meaningful change, because the time there is per-file round trips (footer, then data) that reading ahead cannot remove. Storing a lake as thousands of 1 MB Parquet files is a bad practice anyway, and 2.0 does not rescue it. Fundamentals still matter!
This reads as LLM with no sign of ESL left.
All in all, this seems to follow the recent trend where the very beginning of the article shows the most user input while the rest is mostly generated. The only confounding factor here is the user seems ESL as well but there's still LLM all over.
I've lost count recently of how many times Claude has given me something in this style that I can't understand, and then I ask it to rework parts of it, and then it tells me that the original things it claimed weren't actually quite right anyway.
I'm starting to read it as a sign of low LLM effort not just low human effort. It seems most common when one few-sentence prompt leads it to generate 4+ paragraphs (and the longer the output, the worse the odds). Prompting to dig into each resulting paragraph one by one, to make them readable, makes it do higher-effort deep dives.
I've had that several times. It says something I don't quite understand (complex, jargon, non sequitur or otherwise makes no sense to me), so I ask it to explain, and it discovers it was wrong. And apparently more people are having this experience. Why does that keep happening?
At least it emphasises the importance of truly understanding what Claude is saying. Because if you don't understand it, there's a good chance it's wrong. Do not ever think you're stupid for not understanding something Claude says.
A human has painful memories of past mistakes and knows which of their own thinking process needs to be double checked and which can be accepted on faith. An llm has no such memory, it can either verify every single word or none of them. And verification itself needs to be verified. So they have to stop somewhere.
This is why llm usually produce text that’s too shallow or too detailed.
When you ask the agent to double check something you gave it the missing piece - intuition about which part needs to be checked.
I wonder how much the prevalence LLMlish is causing a shift in normal meatbag's writing style as well?
I definitely add LLMisms to my speech to other techies as ironic jokes, but I've noticed more than once it creeps in naturally. I'm starting to embrace my typos as the few lingering signs of my humanity...
My manager was previously whining about something similar when it comes to generated reports and I just pulled down all of his writing and made the LLM write in his style, he is really content now. Do the same using your own writing and you wont have to be offended
I get the brain scramblies [1] from trying to parse this writing style at work so I hate to see it elsewhere
This sounds to me a lot like mass hysteria, people reading other people's behaviour online and reproducing it unconsciously.
More and more really important and useful information will arrive like this for us to consume. There's no way around. So this is a disservice for newcomers that could come and go unscathed but instead is crippled by these kinds of comments that brings nothing of substance to the table and has the potential to make them hate something they otherwise wouldn't even notice.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Everything is low-effort writing if your judgement is ideologically charged. Just read the damn post, it's very good, there's nothing low effort, but you need to read it as one single piece, not dissect it looking for hints of LLMisms, killing the article in the process.
Also if you think LLMisms so bad it's spam, you also don't get a free pass. From the guidelines:
If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.
Who said I was "ideologically charged"? I like AI and I use it every day. I simultaneously hate AI writing. It is impossible to parse. If you can read it fine, good on you, but you seem to fundamentally misunderstand that other people perceive the world differently than you do. No one is "dissecting" this article under a microscope, it's obvious.
Understanding isn't a prerequisite for following the community guidelines. Everyone here is guilty of this, me included to be feeding this pointless discussion, and it's a bit disappointing from the mods not to terminate this thread. Either that or kill the main post. Keeping both up is contradictory.
This sort of writing decreases readability. People say "just have your own LLM rewrite it" like you don't lose value when you go from prompt -> slop you didn't review enough to clean this crap up in -> someone else's prompt to change the style -> finally someone reads it.
Do you know what happens a double-digit percentage of the time when I ask Claude to rewrite some shit that it gives me like this? It says things like: "I overstated this, I rechecked and actually..." or "this claim doesn't hold up, actually [this other thing is true]..."
So it's a sign that the claims in the post likely weren't vetted very hard.
So if you aren't proofreading I'm gonna be skeptical. And saying "deal with it" doesn't rescue it. Does it?
And then there's the reflexive "you must just be an ideological hater." No. I'm someone who uses the tools in a domain where quality matters enough that I have to dig into the quality of the tool output and spot the tells for when it's low output, so that I can deliver shit that works reliably and consistently.
It's not guesswork. I find it interesting to read comments like the one you're replying to as they echo my own thinking that I've arrived at through my own independent experiences. I'm mindful of confirmation bias though. I've also flagged the submission, as I do for all similar obvious slop articles.
While it's true that 2.0 makes recursive CTEs much more performant, don't forget that there's a badass DuckDB extension for graph data already. Here's a 2025 article about how elegantly that can handle what is otherwise quite a challenging class of query for your typical RDBMS: https://duckdb.org/2025/10/22/duckdb-graph-queries-duckpgq
Great visualization. Side note their new c++ extension api is also gonna be faster from the perspective of development / distribution of those extensions
I wish more database engines used a Task-based design like Umbra / CedarDB.
Most of the DB engines out there still seem to use a "n-threads" style parallelism with exchange operations and poor async I/O management.
DuckDB is improving on this front, but in some sense is catching up to R&D (and implementation!) that is now decades old.
A "rhetorical challenge" I like to give software developers working on systems like this is the following: If I gave you a computer with 1,024 cores and matching network and storage bandwidth -- but with significant latency -- could you keep a system like this 100% utilised with one query?
GPU codes are starting to get there, but CPU codes are way behind on this frontier of computer science.
It's not just databases! Can you (de)compress a file in parallel? Verify its hash in parallel? Upload/download from storage with CPU and I/O task parallelism? Can you overlap all of these operation so nothing is ever waiting on anything else it doesn't have to?
This matters! I ran some tests with bioinformatics codes and found that most got stuck in tar pits. Many could not scale to modern SSDs with millions of IOPS or modern networking with hundreds of gigabits of throughput, no matter how many CPU cores were thrown at them.
Totally valid technique in my opinion. Even with last year's technology, LLMs were really good at synthesis of small details, which, combined with their encyclopedic knowledge of everything ever written down about computers and programming, and their infinite capacity to run adhoc experiments and build out test infrastructure, made them very good at debugging and performance optimization.
I was ok with the AI writing until I got to the fact that they added Triggers in 2.0 and the article decided that was meh compared to optimizing workers for S3 file access on slow connections. Nope. I'll read the release notes myself.
I also love the visualizations but I'm getting heavy LLM vibes from the prose:
> One setting drives this,...
> The cost is now about the rows you actually touch, not rounds times table size.
Etc.
I get the brain scramblies [1] from trying to parse this writing style at work so I hate to see it elsewhere. Apologies if I'm wrong. But if I'm not then OP don't use an LLM to write for you. It's hazardous to your reader's health [2].
[1]: https://www.youtube.com/watch?v=ipUJq-odt5Q
[2]: https://discourse.haskell.org/t/how-to-keep-enjoying-program...
I noticed some AI tells, but found overall the article not too bad. It did seem to waffle at times though.
> Storing a lake as thousands of 1 MB Parquet files is a bad practice anyway, and 2.0 does not rescue it.
The "does not rescue it". No human would write like that.
> I'll explain what that means on a table you already know.
No I don't already know that table.
Also
> and claims 40x on graph reachability
Is really hard to parse.
The section on recursive CTEs wasn't well written and didn't explain how the optimisation was done. This article explains how the recursive CTEs were improved https://duckdb.org/2026/08/25/how-duckdb-runs-recursive-ctes...
> The "does not rescue it". No human would write like that.
This is what I don’t understand. Supposedly LLMs are trained on human text. Why do they come up with such unrealistic prose? Is it intentional because the companies want the tells to be obvious?
They’re not just trained on human prose. They’re sent to RLHF, and also their language changes as a result of RL on verifiable rewards.
Getting it to write well is really hard because there’s no real way to verify whether it’s good prose or not. You and I can tell, but we can’t write a verifier that codifies our judgment.
Maybe they’ll find a way to improve this, but for now it’s certainly one of the harder problems to solve for LLMs.
Part of it is that I think they also have poor theory of mind, which I imagine is also a hard thing to train it to do.
Why is it hard? Ask it to write professionally in mid-twentieth century style English, and without resorting to the clickbait style of writing.
In any event, other LLMs may not automatically have the problem, and don't even require such a prompt. This is a Claude problem.
I don’t think you realize how long ago the middle of the 20th century was.
What does the age of the style have to do with anything? You can ask them to write like Dickens or the King James bible or in Caesar's Latin, too, and these are even older.
In fairness, some of those older styles could alienate a reader, whereas mid-20th century style is practically like our own. To emphasize, this is narrowly about applying the style from an era, not the English from an era.
I don't think you realize the prompt actually works. The word "style" does it. I guess you like clickbait too much.
For autoregressive models (practically all hosted ones), it's because of the nature of next-token prediction. LLMs lock themselves into a particular sentence structure ahead of time and have to guess at the rest of the sentence. Samplers have no insight into the LLM's "intent" aside from the probability of each next token, and the LLM has no insight into its previous "intent" that resulted in a given probability in the first place. I don't know if this is possible to solve with more training, I think a fundamental architectural shift may be needed, like more research into diffusion language models.
I think that's quite a strong claim, especially since chain-of-though reasoning means a modern LLM has its own private scratchpad to workshop sentence structure in, if it were a significant problem.
> The "does not rescue it". No human would write like that.
On the contrary. It is unnatural for a native speaker, which I don't think the author is. For someone that speaks English as a second language, it is not uncommon to use expressions literally translated from their first language, which may be understandable but weird for native speakers.
The author does read to me as genuinely ESL, but there is also blatant LLMish mixed in. Perhaps they used LLMs for translation or drafting. For example:
> DuckDB 2.0 is coming this fall and the alpha is out! I ran the interesting features on my own laptop, and against S3, to see what actually changes for people who build tables and pipelines rather than database engines.
The first sentence looks purely ESL, the second one looks LLM.
> Because yes, DuckDB 2.0 is faster. But to get the speed bump you need to understand how your data is shaped, and sometimes how to model it.
The second sentence here looks LLM as well.
> One comment on the tiny files: no meaningful change, because the time there is per-file round trips (footer, then data) that reading ahead cannot remove. Storing a lake as thousands of 1 MB Parquet files is a bad practice anyway, and 2.0 does not rescue it. Fundamentals still matter!
This reads as LLM with no sign of ESL left.
All in all, this seems to follow the recent trend where the very beginning of the article shows the most user input while the rest is mostly generated. The only confounding factor here is the user seems ESL as well but there's still LLM all over.
Hilarious that even DuckDB's article has many of LLM tells as well
I've lost count recently of how many times Claude has given me something in this style that I can't understand, and then I ask it to rework parts of it, and then it tells me that the original things it claimed weren't actually quite right anyway.
I'm starting to read it as a sign of low LLM effort not just low human effort. It seems most common when one few-sentence prompt leads it to generate 4+ paragraphs (and the longer the output, the worse the odds). Prompting to dig into each resulting paragraph one by one, to make them readable, makes it do higher-effort deep dives.
I never did a blind test but I feel i get much improved writing for work stuff with instructions to use ASD STE-100
I've had that several times. It says something I don't quite understand (complex, jargon, non sequitur or otherwise makes no sense to me), so I ask it to explain, and it discovers it was wrong. And apparently more people are having this experience. Why does that keep happening?
At least it emphasises the importance of truly understanding what Claude is saying. Because if you don't understand it, there's a good chance it's wrong. Do not ever think you're stupid for not understanding something Claude says.
> Why does that keep happening?
A human has painful memories of past mistakes and knows which of their own thinking process needs to be double checked and which can be accepted on faith. An llm has no such memory, it can either verify every single word or none of them. And verification itself needs to be verified. So they have to stop somewhere.
This is why llm usually produce text that’s too shallow or too detailed.
When you ask the agent to double check something you gave it the missing piece - intuition about which part needs to be checked.
I can't stand it. Pangram gives me 95% AI when I run it on just the prose from the article.
It really is unreadable. I guess you're supposed to skim an AI summary. Too bad you'd never see the visualizations that way.
I wonder how much the prevalence LLMlish is causing a shift in normal meatbag's writing style as well?
I definitely add LLMisms to my speech to other techies as ironic jokes, but I've noticed more than once it creeps in naturally. I'm starting to embrace my typos as the few lingering signs of my humanity...
I have tried out the alpha releases of 2.0 and I got slopcoded vibes from it.
I may be in the minority but I didn't get LLM vibes from this. Not enough to be bothered by it, at least
My manager was previously whining about something similar when it comes to generated reports and I just pulled down all of his writing and made the LLM write in his style, he is really content now. Do the same using your own writing and you wont have to be offended
So now we need a decoder to be able to read articles. It's true that it's painful to read and it's good to be called out for it
More and more really important and useful information will arrive like this for us to consume. There's no way around. So this is a disservice for newcomers that could come and go unscathed but instead is crippled by these kinds of comments that brings nothing of substance to the table and has the potential to make them hate something they otherwise wouldn't even notice.
Also, from https://news.ycombinator.com/newsguidelines.html:
Curious how you see low-effort writing as a "shallow dismissal" or "tangential"
Everything is low-effort writing if your judgement is ideologically charged. Just read the damn post, it's very good, there's nothing low effort, but you need to read it as one single piece, not dissect it looking for hints of LLMisms, killing the article in the process.
Also if you think LLMisms so bad it's spam, you also don't get a free pass. From the guidelines:
Who said I was "ideologically charged"? I like AI and I use it every day. I simultaneously hate AI writing. It is impossible to parse. If you can read it fine, good on you, but you seem to fundamentally misunderstand that other people perceive the world differently than you do. No one is "dissecting" this article under a microscope, it's obvious.
Understanding isn't a prerequisite for following the community guidelines. Everyone here is guilty of this, me included to be feeding this pointless discussion, and it's a bit disappointing from the mods not to terminate this thread. Either that or kill the main post. Keeping both up is contradictory.
Look at the specific AI habits called out in this comment: https://news.ycombinator.com/item?id=50037220
This sort of writing decreases readability. People say "just have your own LLM rewrite it" like you don't lose value when you go from prompt -> slop you didn't review enough to clean this crap up in -> someone else's prompt to change the style -> finally someone reads it.
Do you know what happens a double-digit percentage of the time when I ask Claude to rewrite some shit that it gives me like this? It says things like: "I overstated this, I rechecked and actually..." or "this claim doesn't hold up, actually [this other thing is true]..."
So it's a sign that the claims in the post likely weren't vetted very hard.
So if you aren't proofreading I'm gonna be skeptical. And saying "deal with it" doesn't rescue it. Does it?
And then there's the reflexive "you must just be an ideological hater." No. I'm someone who uses the tools in a domain where quality matters enough that I have to dig into the quality of the tool output and spot the tells for when it's low output, so that I can deliver shit that works reliably and consistently.
This is all absurd discussion. If you disagree with the article style, there is a flag button there.
Our time is better used submitting something useful instead of debating meaningless guesswork in the comments.It's not guesswork. I find it interesting to read comments like the one you're replying to as they echo my own thinking that I've arrived at through my own independent experiences. I'm mindful of confirmation bias though. I've also flagged the submission, as I do for all similar obvious slop articles.
> It's hazardous to your reader's health [2].
Just because some guy on some forum said that doesn't make it true. That's not how you establish facts regarding health claims.
The entire internet is like a wikipedia talk page now. If you say it is true often enough it becomes self evident.
Not that i question that reading mostly ai slop for long enough makes you feel dead inside.
Nice article!
While it's true that 2.0 makes recursive CTEs much more performant, don't forget that there's a badass DuckDB extension for graph data already. Here's a 2025 article about how elegantly that can handle what is otherwise quite a challenging class of query for your typical RDBMS: https://duckdb.org/2025/10/22/duckdb-graph-queries-duckpgq
Great visualization. Side note their new c++ extension api is also gonna be faster from the perspective of development / distribution of those extensions
I wish more database engines used a Task-based design like Umbra / CedarDB.
Most of the DB engines out there still seem to use a "n-threads" style parallelism with exchange operations and poor async I/O management.
DuckDB is improving on this front, but in some sense is catching up to R&D (and implementation!) that is now decades old.
A "rhetorical challenge" I like to give software developers working on systems like this is the following: If I gave you a computer with 1,024 cores and matching network and storage bandwidth -- but with significant latency -- could you keep a system like this 100% utilised with one query?
The answer for almost all software is "no".
For example, SQL Server tops out at 64 hardware threads for any one query: https://learn.microsoft.com/en-us/sql/database-engine/config...
GPU codes are starting to get there, but CPU codes are way behind on this frontier of computer science.
It's not just databases! Can you (de)compress a file in parallel? Verify its hash in parallel? Upload/download from storage with CPU and I/O task parallelism? Can you overlap all of these operation so nothing is ever waiting on anything else it doesn't have to?
This matters! I ran some tests with bioinformatics codes and found that most got stuck in tar pits. Many could not scale to modern SSDs with millions of IOPS or modern networking with hundreds of gigabits of throughput, no matter how many CPU cores were thrown at them.
PS: AMD's Zen 6 era EPYC 9006 processors will have 512 cores and 1,024 threads per two-socket system, so this is not hypothetical: https://www.amd.com/en/products/processors/server/epyc/9006-...
Neither one of the two databases you mentioned are open source. There is too much talk and nothing to see here.
It's impossible to parallelize crypto hash operations, if the hash covers the whole file.
You can hash chunks, or maybe use different kind of hashes though.
Sure you can: https://en.wikipedia.org/wiki/Merkle_tree
The leaves and then all nodes can be computed in parallel.
With a typical node size of say 4 KB any file that is at least 4 MB in size can utilise 1,024 cores.
Going to try it out in my next jupyter notebook.
...because Atlas and Fable took turns to go back and forth through it (source code and runtime) and track suspected bottlenecks.
Totally valid technique in my opinion. Even with last year's technology, LLMs were really good at synthesis of small details, which, combined with their encyclopedic knowledge of everything ever written down about computers and programming, and their infinite capacity to run adhoc experiments and build out test infrastructure, made them very good at debugging and performance optimization.
I was ok with the AI writing until I got to the fact that they added Triggers in 2.0 and the article decided that was meh compared to optimizing workers for S3 file access on slow connections. Nope. I'll read the release notes myself.
I was about to comment the same thing. You spend the whole article talking about S3 and explaining recursive CTEs but gloss over triggers?