6 ms·

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?

• musicmatze 2mo ago
  I think a business case for a "look I let an LLM rewrite a large codebase" does not exist.
  • silon42 2mo ago
    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.
• fragmede 2mo ago
  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.
  • pknerd 2mo ago
    Well, I will give 7/10 as an FYP
  • LtWorf 2mo ago
    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.
    • fragmede 2mo ago
      You think that's bad, MongoDB doesn't even have schemas. Schemas!
      • LtWorf 2mo ago
        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.
• egorfine 2mo ago
  It's pure virtue signaling.
  • wartywhoa23 2mo ago
    "Look mum, no brains!"
• wartywhoa23 2mo ago
  Software raidership?
• fulafel 2mo ago
  [dead]
• booksock 2mo ago
  (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-postgres-outages/ https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • solid_fuel 2mo ago
    > 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.
    • booksock 2mo ago
      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
  • rozhok 2mo ago
    Wondering if its possible to backport performance improvements into upstream. Should be a big deal.
    • menaerus 2mo ago
      I'd say it would be most likely impossible.
  • dstanko 2mo ago
• signatoremo 2mo ago
  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.
• wkoszek 2mo ago
  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.