It is theoretically possible to have a Rust port of Postgres support extensions. If you make all the relevant functions and structures ABI compatible with Postgres, extensions should work. The issue is the moment you're dealing with C pointers and C strings, pretty much all the code you have to write is unsafe.

Perhaps pure pgrx extensions would make sense as a first target?

They would need to be rewritten as there is no formal extension API. Extensions can call into almost any part of PostgreSQL.

They would need rewriting (a few are included)

Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.

So how much AI usage does it make it an “AI rewrite”?

Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.

Who wants to contribute to an unmaintainable code base?

> I think close to 100% of new ambitious projects are going to leverage AI at least to some degree.

Once the free money dries up that number will rapidly tend towards 0%.

> So how much AI usage does it make it an “AI rewrite”?

Any amount.

Unfortunately there is currently an issue in pnpm that makes `minimumReleaseAge` difficult: https://github.com/pnpm/pnpm/issues/11068

That might be opus 4.7 behaviour because I also get that all the time in the past few weeks. Also complex code base, but likely an order of magnitude simpler than yours.

This rings true to me. Rust is great but in environments where you need a lot of unsafe anyway, it’s still not memory safe, and adds complexity otherwise.

That explains why `sync` and `worker` have so similar results in almost all runs. The benchmarks from Tomas Vondra (https://vondra.me/posts/tuning-aio-in-postgresql-18/) showed some significant differences.

Yeah, I don't think "fixing" is really the right term here, since this brings a different set of tradeoffs. You don't leak timestamps, you get ok page locality, but you lose the ability to sort by the IDs. I do see how this might be a good choice for a general PK default (i.e. by default, don't leak stuff).

It's Postgres specific but there is https://github.com/xataio/pgroll which takes the automation a step further.

This is very interesting, thanks for offering to answer questions. I'm curious of two things:

* Are you also considering going the Postgres extension route, like Citus? It is after all the best attempt at sharding Postgres so far.

* If you are willing to share, why not doing this from inside Planetscale? I assume it was at least considered over the years.

It will be a proxy layer. Since Vitess has proven itself with this approach, I don't see a reason to try anything drastically different. As for Planetscale, I've posted my thoughts on X and LI :).

Other relevant talks/blogs that I found really useful for understanding Postgres locks are:

* Unlocking the Postgres Lock Manager by Bruce Momjian: https://momjian.us/main/writings/pgsql/locking.pdf

* Anatomy of table-level locks by Gulcin Yildirim Jelinek: https://xata.io/blog/anatomy-of-locks