I don't know why anyone would choose this over the actively (community) maintained proper Postgres project.
I don't know why anyone would choose this over the actively (community) maintained proper Postgres project.
The project is not cool. This is not a new idea, and there is nothing special.
Students won't use it as an example of porting code. I am not aware "porting code" is part of standard software engineering or computer science curriculum. That's not the kind of thing being taught in schools.
Companies won't switch to it unless their CTOs are either insane or incompetent.
I published similar project here: www.emuko.dev - emulator for RISC-V. This one turned out to be 3x as slow as QEMU for example.
re: CTOs - if the improvement is 3% nobody of course will look at it. If the improvement is 30%, it'll be too big for big players to ignore, so as a CTO you'll be tasked with trying it out. It's really a matter of whether this thing is safe and secure, losing data or has a trojan. If the authors can prove it's all valid working code etc., it'll be a viable project.
Sorry, as someone who has been involved in many of these decisions, I don't think you understand how any of this actually works in the real world.
It's also worth noting, that while you are able to use LLM's to produce your own translation, he's actually done it. There's value in actually putting in the work.
This isn't a unique situation at all. Many Postgres extensions are developed and maintained by a single person, and may therefore be avoided by more conservative users, even if they offer some technical advantages. To each, their own.
He has provided benchmark results which provide a dimension amongst which to measure your rewrite. If you can do better by all means post your rewrite.
Finally, these kind of projects can eventually over time become projects that are actively used. Postgres is not some entity that existed before the universe was created; it was also created by someone and then eventually adoption picked up over time.
It has a 40ish year continuous history. (Which is also why it has technical/design warts like process-per-connection that we probably wouldn't do in 2026, but that's another story.)
Even with that I remember getting funny looks 20-ish years ago when I would advocate for using it instead of MySQL.
With databases, reputation is everything.
But I choose not to publish it or promote it for many of the reasons you mention above (and more)
... For one, if "I" can do it, so can a hundred other people. And all the bold claims behind it would need to be backed up and supported and it promoted, etc, which is a whole pile of time that doesn't involve writing code.
It's the organization around a project that matters, not the code. It's not the 90s anymore w/ people piling into MySQL because it was the only option. People aren't going to be trusting your software with their data, if they can't trust you.
And unless someone is going to dump a pile of money or something on [me|them], I don't have the ability to build that organization ... as I need to feed my family... Nor am I willing to put my personal reputation on the line by putting up a huge quickly written application and then someone finding something in it I can't explain.
So like probably 500 other projects I have it sitting in a private repo.
It's a very weird time right now. "Technical" excellence isn't the important part. Organizational excellence is. This was always the case but it's more so now.
... In the meantime, if anybody has angel investment to burn, I have something potentially better/more-exciting than this guy's project but... see above...
Translations are a lot more likely to be error-free and robust, as the original data structures and algorithms have been battle tested.