3 ms·

(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 i

(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 3mo 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 3mo 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 3mo ago
Wondering if its possible to backport performance improvements into upstream. Should be a big deal.
- menaerus 3mo ago
  I'd say it would be most likely impossible.
dstanko 3mo ago
Why not then doing it as a fork - using existing code and language to re-architect? What value does Rust bring here? You are using LLMs to rewrite, so the language is pretty much irrelevant from developers perspective. You can say "we want it in Rust" and leave it there - I'd be fine with it. Wouldn't use it though.

solid_fuel 3mo 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 3mo 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 3mo ago

Wondering if its possible to backport performance improvements into upstream. Should be a big deal.

menaerus 3mo ago
I'd say it would be most likely impossible.

dstanko 3mo ago

Why not then doing it as a fork - using existing code and language to re-architect? What value does Rust bring here? You are using LLMs to rewrite, so the language is pretty much irrelevant from developers perspective. You can say "we want it in Rust" and leave it there - I'd be fine with it. Wouldn't use it though.