malisper

“easy” seems to be doing a lot of work here, but anyway there is malisper/pgrust if (like me) you accept that code is design then we already have a spec - the C source code. So it should be “easy” to translate it to safe rust, right? but such a project not only changes the language but also the custodians. pg has been very good to me over the years and I’m not sure I would trust an unrelated team to maintain the very high standard that this project has consistently provided for 20+ years.

@charliermarsh pg-rust is an interesting one for this: malisper/pgrust

拿 Rust 把 Postgres 照着行为重写一遍，查询执行和内存占用都自己管，装完能用 psql 直接连上去。 malisper/pgrust Michael Malis 照着 PostgreSQL 18.6 的行为，用 Rust 从头实现了一套数据库，连协议和 SQL 方言都对得上，老客户端不用改代码。 t.co

@laravel Any willingness to consider supporting malisper/pgrust on Laravel Cloud as an option? I'm asking because, "Measured on c8g.4xlarge (AWS Graviton4), pgrust with pgrcolumnar, its builtin columnar layout, runs ClickBench's analytical queries up to 1,600x faster than PostgreSQL".

The core idea is "programming at light speed". We start with the fastest possible query implementation. Then we figure out what optimizations we need to achieve similar performance. Code: malisper/pgrust

pgrust: A Rust rewrite of Postgres (5.5k stars) What it does All text below is quoted directly from the project README. >Postgres rewritten in Rust, now faster than Postgres and Clickhouse pgrust has: - Gravity, a new vectorized push-based, JIT compiled query engine - A thread based concurrency model - A query scheduler designed to keep any individual query from taking down your database - An automatic memory manager: one memory budget, sized from the machine, covers the buffer pool, the columnar caches and running queries, and gives pgrust control of what happens when you're running low on memory, greatly reducing the chance of your whole DB being taken down by the OS OOM killer >In your browser: pgrust.com, a full pgrust server compiled to WebAssembly, no install. Repository malisper/pgrust Repository stats |Metric|Value| |:-|:-| |Stars|5,539| |Forks|214| |Last release|v0.4-beta (2026-10-22)| |Languages|Rust 64.7%, C 27.3%, PLpgSQL 2.1%| |Contributors|5| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (1 commits)| |AI co-authored commits|None| Main contributor |Field|Value| |:-|:-| |Name|Michael Malis| |GitHub|@malisper| |Commits to this repo|3 (top contributor)| |Bio|Creator of pgrust, prev founder of @freshpaint-io.| |Company / Location|Freshpaint / San Francisco, Ca| |Followers|247| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.

we don't have the commits we need to audit the first commit has 400k files, the other two more than 1000 each, if you are going to ask others to audit this scale of ai generated code, can you tell us what you have done to audit it? What I have seen is your Ai adding a lint test to make sure it doesn't cheat again. Are you personally aware of this file? How can you ensure it doesn't alter it and reinject the hand rolled benchmark queries? Will you be reviewing changes more thoroughly going forward? github.com/malisper/pgrust/blob/38634b408dea373f3… transparency is the way to end the controversy, which appears to be sharing the full commit history based on HN responses For clarity, I do not think you personally cheated or did anything nefarious. This is more another example in the "too much eyes free coding" columnar database.

> This aged like milk. pgrust was caught cheating on all benchmarks this week. Can you back this up? Our code is open source here[0]. You're free to audit it and benchmark it as much as you want. You'll find it's just as fast as we claim it is [0] malisper/pgrust

Hi! I'm the creator of pgrust. Let me explain what happened. For the most part, the actual accusations are false. This submission was an earlier version of pgrust 0.4 called pgrust 0.4-preview. We just open-sourced a newer version called pgrust 0.4-beta yesterday, and you can fully audit it here[0]. Rather than contest the accusations on GitHub, we figured it would be easier to complete pgrust 0.4 and open-source it to show that we're being honest. You can also verify what I'm saying yourself against the 0.4-preview binary we submitted to ClickBench here[1]. I don't have a way to prove this is the exact binary submitted, but if ClickHouse provided the SHA of the binary they tested against, it would match. The three main accusations boil down to: 1) We used handwritten code optimized against each query in the benchmark, 2) We cached the results between query runs, and 3) We didn't support queries outside of the 43 ClickBench queries. First, we did not use handwritten queries. The code Alexey pointed out does not run during the benchmark. The design of 0.4 relies on a JIT compiler that compiles your SQL to a Lisp-based intermediate representation that we call Gravity IR that we then convert to x86 and ARM assembly. While developing 0.4, I wrote handwritten code against the IR for benchmarking purposes. The idea was that if queries written in our IR are fast, and we can compile good enough IR fast, then our new query engine will be fast. This is also the reason the directory those "kernels" are in is called "irprobe" - it was a probe of our IR to make sure it was fast. Our 0.4-preview submission went through the pipeline: SQL query -> Gravity IR -> assembly. Second, the "result-cache" Alexey observed is the result of a cache we use to cache which predicates match which strings in our dictionaries we use for dictionary compression. Alexey wasn't aware of this cache and assumed we were just caching the query results. On ClickBench you are allowed to use caches like this that hold intermediate data[2]. ClickHouse has its own cache similar to this called the Condition Cache[3]. In our newest submission, we were upfront about all the caching we do and how to disable each cache[4]. The third claim that we didn't support other queries outside of the 43 ClickBench queries is partially false, but does have some ground to it. As I said before, pgrust 0.4-preview was an early version of pgrust 0.4. Once our new JIT compiler supported enough SQL to handle the ClickBench queries, we decided to submit it to ClickBench. AFAIK, ClickBench has no rules about how much SQL you need to support. On top of that, we did ship that we did ship 0.4-preview with our old query engine. It would have been a two-line change to fall back to it and support a much broader set of queries outside what our new engine could support. Those queries would still be fast, but not quite as fast as our new engine was. Our new 0.4-beta release does now support all Postgres SQL (minus some bugs around CTEs and MERGE) To sum up, pgrust 0.4-preview was an early build of pgrust 0.4 while it was in development. It was a real query engine and actually executed queries. I acknowledge that we submitted it prematurely, when it supported a narrow set of SQL, and we should have ensured broader SQL coverage before submitting it. With our new submission that solves these problems, and we're hoping for pgrust to be reinstated. If there's anything off about the submission, please point it out and we're happy to fix it. [0] github.com/malisper/pgrust/releases/tag/v0.4-beta [1] pgrust.com [2] github.com/ClickHouse/ClickBench/blob/main/README… [3] clickhouse.com [4] ClickBench#2751

The project author seems to have prompted Claude to add a test to catch Claude cheating, but will Claude change this test as a workaround in a future commit, no one knows because no one is reading the project code... github.com/malisper/pgrust/blob/38634b408dea373f3…