I am not trolling, but I have a simple question: Why? Why do I use this instead of the official build? What is the business case?
I am not trolling, but I have a simple question: Why? Why do I use this instead of the official build? What is the business case?
(I'm working with malisper on this), we are now focusing on improving many things about postgres! Some we have written about before [0], and we have much more in mind too. Malis wrote another comment about analytical workloads being 300x faster now than postgres for a version we're working on right now
Aiming for postgres compatible database with a 2026 architecture
[0] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
> Aiming for postgres compatible database with a 2026 architecture
Except you didn't improve the architecture, did you? You just asked an LLM to copy what was already there. Making real improvements to the database architecture requires understanding the database architecture, not just asking a calculator to do the work for you.
Better benchmark performance means nothing if the underlying guarantees break, and a 300x improvement sure makes me suspicious. I would look at something like this if it passes a Jepsen test, otherwise you simply will not be able to convince me that it's worth my time.
The version we have live right now is pre architecture changes, we wanted to make sure we could hit this milestone first. And agree about proving the underlying guarantees. It will be pretty exciting when we do
Wondering if its possible to backport performance improvements into upstream. Should be a big deal.
I'd say it would be most likely impossible.
I think a business case for a "look I let an LLM rewrite a large codebase" does not exist.
You are now at 0.1%... now submit upstream in sensible chunks (function or maybe file/module), waiting for people to review (a few per week, maybe) and approve/merge.
There is big appetite for PostgreSQL in business cases. But there's also a lot of problems in PG and people want to solve them. But there's ~10 people in the core of PostgreSQL who contribute to it and know how to change the core. If you have a business use case that would require changing the core, doing it in safer, less error prone technology would be way better. That's why you have other products that had to be created that talk PG protocol, but aren't using official build.
Why not? The author have their own reasons to do it. Did they ask you to use it instead of the official build? It's a github repo.
Why does there need to be a business case? They aren't selling it.
Software raidership?
It's pure virtue signaling.
"Look mum, no brains!"
Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. There might be performance benefits down the road if they choose to focus on that.
Well, I will give 7/10 as an FYP
Rust doesn't have ACID and I'm sure this doesn't either.
I'd like to know if the "authors" know what I'm talking about.
You think that's bad, MongoDB doesn't even have schemas. Schemas!
Oh we used it in my first job. It was really slow and the data in there was all buggy.
We really should have used postgres instead, but it was the "big data" period so you had to use mongodb.
[dead]