new | show | ask | jobs Github

meow9 3 hours ago

I’m still amazed that with all the vibe coding, no one has created a Postgres alternative

▲ TomatoCo 3 hours ago | parent | next [-]

Someone tried. https://jepsen.io/analyses/particledb-1.1.4

▲ nfriedly 3 hours ago | parent | prev | next [-]

Why would they? Postgres is free and does an amazing job.

▲

sapphire4 3 hours ago | parent | next [-]

I wish they'd adopt, merge in, or give official blessings to versioned postgres extensions like citus and pgvector.

	▲	nimchimpsky 3 hours ago \| parent [-]
		why ? Just install the extension and use it

▲

spolitry 3 hours ago | parent | prev | next [-]

Also Postgres has enjoyed decades of debugging.

▲

scrollaway 3 hours ago | parent | prev [-]

To be honest I would love for someone to work on the structuring of pg_dump for example, which is entirely driven by regexes and binary structures. It’s awful and absolutely not programmable - a real shame.

▲ esalman 3 hours ago | parent | prev | next [-]

You can create a project on vibes, but you cannot maintain one on vibes.

▲ sa46 3 hours ago | parent | prev [-]

Many recent relational databases speak the Postgres wire protocol. For wholesale replacement, pgrust is a recent, contentious contender.

▲ gnabgib 3 hours ago | parent [-]

I hope you don't believe this, PGRust has fallen far from grace. Wire protocol support is useful (other than said recommendation)

Remove pgrust: the entry is cheating (per-query kernels and result caching) (197 points, 10 days ago, 166 comments) https://news.ycombinator.com/item?id=50205816

	▲	malisper 3 hours ago \| parent [-]
		I work on pgrust. We shouldn't have submitted the preview when we did: it was still in active development, and its SQL coverage was far too narrow, though there was nothing in it giving it an unfair performance advantage For the other two claims in the removal PR, we wrote scripts you can use to verify the behavior of the original 0.4-preview binary: `- Per-query kernels did not serve the benchmark queries[0] - The preview's fast repeat LIKE queries came from a dictionary filter cache, not a cached query result[1]` Our open-sourced 0.4-beta has now been merged and is back on ClickBench[2][3] Across all queries and instance sizes on ClickBench, 0.4-beta is ~7% faster overall than the 0.4-preview binary that was removed. If 0.4-preview's numbers had come from hardcoded kernels or faked results, the open-source general engine wouldn't be beating it [0] https://pgrust.com/downloads/archive/2026-09-clickbench-snap... [1] https://pgrust.com/downloads/archive/2026-09-clickbench-snap... [2] https://benchmark.clickhouse.com/ [3] https://github.com/ClickHouse/ClickBench/pull/2751