Maintainer takes over pg_mooncake extension one day after rescuing vchord in PostgreSQL

On November 5, 2026, Ruohang Feng, creator of the Pigsty distribution, published a direct account on Planet PostgreSQL: one day after taking over maintenance of the vchord vector search extension, he repeated the process with another extension of similar size, pg_mooncake. Both written in Rust, both abandoned for market reasons, not for lack of technical quality.

The case matters to anyone running PostgreSQL in production for a simple reason: an extension isn't an application library you swap out with an npm install. It hooks into the database process, needs to compile against the right server version, and when it depends on another extension, it carries that dependency's risk along with it.

The trigger was an acquisition, not a bug

pg_mooncake was originally maintained by Mooncake Labs, a team that was acquired by Databricks. According to Feng, this is a recurring pattern in open source: when a startup is absorbed by a larger company, the repository it leaves behind rarely goes back to receiving active maintenance. The code doesn't disappear, but it stops evolving, and that's exactly what happened here: the upstream repository went quiet for more than a year.

The problem is that silence in infrastructure code has a shelf life. pg_mooncake is a sub-extension built on top of pg_duckdb, which embeds DuckDB's analytical engine inside Postgres to enable columnar tables and reading formats like Iceberg and Delta Lake directly from the transactional database. When DuckDB released version 2.0.0 with substantial internal changes, pg_duckdb needed a new release to keep up. And since pg_mooncake depends directly on pg_duckdb, updating the parent extension without updating the child in lockstep simply breaks the child.

The three-step playbook

Feng describes the takeover process as a repeatable sequence, already run one day earlier with vchord:

1. Recover the documentation. The official mooncake.dev site now redirects straight to Databricks; the original documentation disappeared from the live web. Feng recovered the full content, including old engineering blog posts, from Internet Archive snapshots, and republished everything.
2. Update the code for the current stack. The extension was frozen at version 0.2. Feng moved it to 0.3, updated compatibility with pg_duckdb 1.2, and bumped the pgrx framework (used to write Postgres extensions in Rust) to version 0.19.3.
3. Keep it at a low pace. Without bringing the extension back to a constant release cycle: just point updates whenever a new PostgreSQL major version ships or when pgrx and pg_duckdb release new versions, plus reasonable feature requests from real users.

The motivation Feng states isn't abstract altruism: he says he knows several Pigsty users run pg_mooncake in production, and says one of the worst things a distribution maintainer can do is ship an extension in one release and then simply let it disappear in the next.

The rescue doesn't always have to come from a single hero

The text itself brings up a counterpoint worth keeping in mind. Apache AGE, a graph database extension for PostgreSQL, stagnated when its lead maintainer lost his job. Feng even considered taking over a fork, as he's now done with vchord and pg_mooncake. But in that case, renewed demand for graph workloads brought new people into the project, and it recovered on its own, without needing an external fork.

The lesson here isn't that every abandoned project has a guaranteed savior. It's that an extension's fate depends on two factors the developer rarely controls: the size of the real user community behind it, and the luck of having someone with knowledge of Postgres internals willing to take on maintenance when the community alone isn't enough.

My job as a distribution maintainer is to compile, package, and deliver working software. Even when an upstream team moves on, the distribution layer should absorb the shock and keep the software supply chain intact for downstream users.

Ruohang Feng, creator of Pigsty

What changes for those running extensions in production

For the developer or DBA who depends on third-party extensions in PostgreSQL, the episode leaves three practical takeaways, regardless of whether they use Pigsty or not.

First, transitive dependency between extensions is a real versioning risk, not just an application-level one. The same problem you already face with package.json or go.mod exists between native extensions: pg_mooncake broke because its direct dependency, pg_duckdb, had to keep up with an upstream change in the DuckDB engine itself. Before adopting a niche extension, it's worth mapping its dependency tree, not just the extension itself.

Second, upstream repository activity is production data, not a curiosity detail. A year of silence in a repository critical to your analytics stack is a warning sign before the breakage happens, especially when the original team was absorbed through an acquisition, as happened with Mooncake Labs at Databricks.

Third, distributions like Pigsty play a role here equivalent to a Linux distro: packaging, testing, and ensuring compatibility across PostgreSQL major versions so the end user doesn't have to track every upstream commit. According to Feng, both vchord and the updated pg_mooncake are already available in Pigsty's extension repository, with pre-built packages for PostgreSQL 14 through 18 across 16 operating systems, installable via the system's package manager or direct download.

This doesn't eliminate the risk of depending on a fork maintained by a single person: if Feng stops updating it tomorrow, the problem comes back. But for those already running pg_mooncake in production, swapping a silent dependency for an active, documented fork is, in practice, the only reasonable path until Databricks decides (or not) to pick the original project back up.