Gotta say this site is killing it in the LLM-written technical blog SEO game the last couple years, they're consistently able to dominate (and actual deliver in spite of the LLM-isms) SERP for a set of technologies that very closely align with the ones that a typical backend/infrastructure engineer would work on.
I checked their list of blog articles from the last year and they haven't even written that many, which makes it quite impressive because they really model the set that I've been working with (Go, Postgres, grpc, otel) well by I guess defining some kind of customer archetype and writing really detailed guides about what they'd be interested in learning more about. At this point I've encountered their site "organically" like 5x in the last year and recognize the name/style of content so they're doing something right in the marketing department for sure.
On one hand you could just dismiss it as spam but articles like this actually represent a pretty significant LLM spend/human review element that delivers real value to me as a technical end user looking for info on google or in technical blogs on HN (ie it would take me a long time to generate something like this myself and I wouldn't do it proactively, only when-needed). So it actually does help me quite a bit that they do so before I think to ask about it.
I just can’t get over that slightly detached, nauseating feeling that follows the realization that I just read 3 long sentences that said very little. It’s almost like it’s possible to sense there is an underlying prompt and what you are actually reading is an expansion
The way I process this kind of content is by skimming or ctl-Fing for the material I'm interested in reading and usually just reading the example code or the specific explanation for the content I'm after
For example this site ranks on the first page for "go 1.27 generics" and "go 1.27 uuid"[0] and if I were looking for uuid content I'd probably click on the toc for uuid and go to here [1] and look at the examples and v4 vs v7 semantics and then bounce. For this particular article the thing I'd be most interested in applying is probably REPACK [2]
REPACK (CONCURRENTLY) events;
And all of the content around their code snippet showing that is pretty prescient/semantically dense and useful. What I wouldn't do is read the whole thing front to back, or the prose at the top/bottom with the LLMisms: it's way too long and dense for that.
For comparison here are the official new postgres docs about REPACK [3]. Is it human-written and more informative? Maybe for some people, or for me if I needed to reimplement a postgres-compliant spec or something, but I'd prefer the LLM-assisted (and I say assisted because IME it's actually a decent amount of work to get LLMs to write content like this) article most of the time.
I first encountered them in various stackoverflow answers, this is the next step. IIRC they did promote themselves but it was subtle and the answers were good.
The features look exciting, but the article is exceptionally unclear to me. I am not sure whether that is my fault, the author's, or the LLM's who wrote it.
`on conflict do select` and eager aggregation are the most notable for me, I use upserts and joins like that all the time. Annual postgres upgrades are always exciting (features) and terrifying (ops) :D (not that something can go wrong, I just feel anxiety hehe)
The interactive format is especially useful for teaching version-specific behavior, but I’d pair each example with EXPLAIN (ANALYZE, BUFFERS) so readers can see when the planner’s choice changes on a real workload. A short note about statistics freshness and extended statistics would also help prevent readers from treating the demo plan as universally optimal.
I came to the comments to see the discussion and almost all of them are just complaining about LLM-assisted writing.
It's exhausting and tedious, like people nitpicking grammar.
It's also off-topic. I'd love it if HN banned (or strongly discouraged) this kind of repetitive low-value off-topic meta-discussion.
We get it, LLMs are used to write now. Some people don't like it. No need to broadcast that dislike every time, it adds noise to the discussion. :-(
(yes I realize I am also adding off-topic noise but this thread was nothing but that, so I guess I am on-topic until actual Postgres discussion starts).
I urge you to read the article. "assisted" is doing a lot of load-bearing work here.
The problem is not just the writing style, but rather that it doesn't make sense at all.
Take the example for PGQ. "Two ordinary tables, one graph on top of them:" The example makes zero sense, because the fucking tables aren't even there. You can't be lazier than writing a prompt: "please make a blog post about the new PostgreSQL release, and give code examples for each new feature", then ctrl-c, ctrl-v the output.
You can write articles with the most horrible style if you want, but this level of disdain for readers is beyond belief.
You can add the following statements in the first example and click "Run" button in order to understand the underlying tables' structure and contents mentioned in the example:
SELECT * FROM person;
SELECT * FROM follows;
You can explore the database used in this example with any valid PostgreSQL statements.
Gotta say this site is killing it in the LLM-written technical blog SEO game the last couple years, they're consistently able to dominate (and actual deliver in spite of the LLM-isms) SERP for a set of technologies that very closely align with the ones that a typical backend/infrastructure engineer would work on.
I checked their list of blog articles from the last year and they haven't even written that many, which makes it quite impressive because they really model the set that I've been working with (Go, Postgres, grpc, otel) well by I guess defining some kind of customer archetype and writing really detailed guides about what they'd be interested in learning more about. At this point I've encountered their site "organically" like 5x in the last year and recognize the name/style of content so they're doing something right in the marketing department for sure.
On one hand you could just dismiss it as spam but articles like this actually represent a pretty significant LLM spend/human review element that delivers real value to me as a technical end user looking for info on google or in technical blogs on HN (ie it would take me a long time to generate something like this myself and I wouldn't do it proactively, only when-needed). So it actually does help me quite a bit that they do so before I think to ask about it.
I just can’t get over that slightly detached, nauseating feeling that follows the realization that I just read 3 long sentences that said very little. It’s almost like it’s possible to sense there is an underlying prompt and what you are actually reading is an expansion
The way I process this kind of content is by skimming or ctl-Fing for the material I'm interested in reading and usually just reading the example code or the specific explanation for the content I'm after
For example this site ranks on the first page for "go 1.27 generics" and "go 1.27 uuid"[0] and if I were looking for uuid content I'd probably click on the toc for uuid and go to here [1] and look at the examples and v4 vs v7 semantics and then bounce. For this particular article the thing I'd be most interested in applying is probably REPACK [2]
And all of the content around their code snippet showing that is pretty prescient/semantically dense and useful. What I wouldn't do is read the whole thing front to back, or the prose at the top/bottom with the LLMisms: it's way too long and dense for that.For comparison here are the official new postgres docs about REPACK [3]. Is it human-written and more informative? Maybe for some people, or for me if I needed to reimplement a postgres-compliant spec or something, but I'd prefer the LLM-assisted (and I say assisted because IME it's actually a decent amount of work to get LLMs to write content like this) article most of the time.
[0] https://www.google.com/search?q=go+1.27+generics
[1] https://victoriametrics.com/blog/go-1-27/#the-uuid-package
[2] https://victoriametrics.com/blog/postgres-19/index.html#repa...
[3] https://www.postgresql.org/docs/19/sql-repack.html
I first encountered them in various stackoverflow answers, this is the next step. IIRC they did promote themselves but it was subtle and the answers were good.
The features look exciting, but the article is exceptionally unclear to me. I am not sure whether that is my fault, the author's, or the LLM's who wrote it.
The headline feature (property graphs) has a better example here in the official docs: https://www.postgresql.org/docs/19/ddl-property-graphs.html
I am interested in what features postgresql 19 has .. and would like to see a summary that starts with a bullet list of highlights.
I found this tour unreadable.
Here's the official release notes page : https://www.postgresql.org/docs/19/release-19.html
which unsurprisingly does have a list of important changes near the top.
to be fair .. the tour does have a list of contents on right hand side, which I noticed much later.
and sql examples.
I guess we are in the age of "Ill get my people to talk to your people" or "Ill get my AI to summarize your AI output"
The benefit of a guide would be it tells me what the main changes are, why they matter, with pithy illustrative usage examples.
I guess I have an aversion to idiomatic [ ego-massaging, feelgood ] LLM-speak.
`on conflict do select` and eager aggregation are the most notable for me, I use upserts and joins like that all the time. Annual postgres upgrades are always exciting (features) and terrifying (ops) :D (not that something can go wrong, I just feel anxiety hehe)
Tangential, but the Claude-isms make it a less rewarding read
It is getting quite nauseating to see Claude's fingerprints all over the page and at this point I just expect the slop to continue.
But the payoff here is that you get a sneak peak into PG19
It's off-putting to me too. I wonder if the AI enthusiasts that stopped manually writing also find it off-putting
No you see when I generate a blog post it’s not slop. You see I reviewed the output and declared everything is fine. So it’s not slop.
It’s only when you generate a blog post that I get the ick from slop.
Because I clearly put effort into my blog post and you did not.
When models start to effectively employ sarcasm were screwed
Does Postgres 19 support full temporal tables, or what's landing is a subset of that?
The interactive format is especially useful for teaching version-specific behavior, but I’d pair each example with EXPLAIN (ANALYZE, BUFFERS) so readers can see when the planner’s choice changes on a real workload. A short note about statistics freshness and extended statistics would also help prevent readers from treating the demo plan as universally optimal.
You can add missing EXPLAIN statement to all the examples in the article - they are editable and interactive.
I came to the comments to see the discussion and almost all of them are just complaining about LLM-assisted writing.
It's exhausting and tedious, like people nitpicking grammar.
It's also off-topic. I'd love it if HN banned (or strongly discouraged) this kind of repetitive low-value off-topic meta-discussion.
We get it, LLMs are used to write now. Some people don't like it. No need to broadcast that dislike every time, it adds noise to the discussion. :-(
(yes I realize I am also adding off-topic noise but this thread was nothing but that, so I guess I am on-topic until actual Postgres discussion starts).
Take the example for PGQ. "Two ordinary tables, one graph on top of them:" The example makes zero sense, because the fucking tables aren't even there. You can't be lazier than writing a prompt: "please make a blog post about the new PostgreSQL release, and give code examples for each new feature", then ctrl-c, ctrl-v the output.
You can write articles with the most horrible style if you want, but this level of disdain for readers is beyond belief.
You can add the following statements in the first example and click "Run" button in order to understand the underlying tables' structure and contents mentioned in the example:
You can explore the database used in this example with any valid PostgreSQL statements.I must say I was immensely entertained by reading "IBM stepped up with buildfarm animals". :)