Yesterday’s post “PG ‘Export Controls’ and Supply-Chain Trust” drew a comment from someone claiming to be an admin at a university mirror site (Tsinghua TUNA):
“As a university mirror admin, calling us ‘lying flat’ or ‘irresponsible’ is unfair and demoralizing.”

I replied:
Thanks for the feedback and for everything TUNA/university mirrors have done over the years. I see the PostgreSQL repo has synced again—credit where it’s due.
When I first spotted the issue I was using Alibaba-Cloud’s PG mirror. Later I noticed TUNA was in the same state, so out of community duty I reported it on the mailing list and got “this list isn’t for Alibaba” followed by silence. That context colors my tone.
In hindsight, words like “lying flat” were too emotional—especially when applied to your team—and read like moral judgments on volunteers. That wasn’t my intent. If the wording hurt maintainers, I apologize. I already changed the language to neutral phrasing like “stale” or “no longer maintained.”
You’re right: university mirrors are volunteer efforts with no contractual SLA. There’s nothing to “demand.” But from a downstream perspective, when PGDG cuts rsync and major domestic mirrors stall for months, users depending on “recommended mirrors” experience a supply-chain outage. Trust erodes.
My takeaway: if there’s no service promise, treating a volunteer mirror as production infrastructure is a mistake. My own fix is to stop relying on external mirrors altogether—Pigsty now mirrors PGDG ourselves. Your perspective helps others understand what mirrors can and can’t do, which is valuable.
My reflections#
I checked TUNA again—PG 18 packages are there, though “Last Update” still shows 2025-05-16, so it was probably a manual sync. That’s great news: aside from Pigsty’s PGEXT Cloud, we now have another local node with reasonably fresh PGDG content.

Pigsty originally pointed at Alibaba’s mirror, not TUNA. My “lying flat” rant was aimed mostly at a well-funded company doing the bare minimum—classic Cloud Mudslide material. Alibaba reaps enormous value from PostgreSQL yet let the repo rot. Ironically, it was the TUNA folks who responded, which I understand.

To be fair: neither Alibaba nor TUNA owes anyone anything. I said that repeatedly in the original piece. Free services don’t come with legal or moral obligations. But that doesn’t stop people from reacting to outcomes. Calling it “lying flat” was my subjective frustration—misplaced when applied to university volunteers, so I toned it down.
Why the frustration? When I noticed the global sync breakage, I immediately emailed Alibaba (still unresolved). I also checked other domestic mirrors and saw TUNA stuck, so I sent the same heads-up. The only reply was “not our business.” Months passed, nothing changed, and the repo remained outdated. From a downstream point of view, the mirror was effectively dead.
When you’re running mission-critical systems, you can’t depend on an upstream saying “no guarantees.” The right response to “don’t count on me” is “fine, I’ll run my own supply chain.”
Pigsty now ships everything from our own repo:
- Full PostgreSQL releases
- 450+ extensions for EL9, EL8, Debian 12, Ubuntu 22/24
- Ecosystem packages: IvorySQL, FerretDB, TigerBeetle, JuiceFS, Kafka, DuckDB, MinIO, etc.
- Observability stack: Prometheus, VictoriaMetrics, Grafana, Loki, exporters
- Utilities: Sealos, rclone, restic, sqlcmd, genai-toolbox, etc.
(See the table at the end of this article for full lists.)
Trust is earned. You can’t offload that responsibility to someone who told you, up front, “this is best effort.”

Lessons#
- Volunteers aren’t your SLA. University mirrors are goodwill projects. Treating them as production vendors is unfair to them and dangerous for you.
- Corporate mirrors should do better. If a hyperscaler profits from open source, it should keep its public mirrors current or shut them down.
- If trust matters, self-host. Mirror what you need, automate the sync, and monitor it.
Below is the current snapshot of what Pigsty mirrors (PostgreSQL ecosystem, observability stack, and tooling). When someone asks “where do you get your packages?” I can point at a repo we control end to end.
| DBMS | Prometheus stack | Grafana/Observability | |||
|---|---|---|---|---|---|
| IvorySQL 4.6 | prometheus 3.7.3 | grafana 12.3.0 | |||
| etcd 3.6.6 | pushgateway 1.11.2 | loki 3.1.1 | |||
| minio 20250907161309 | alertmanager 0.29.0 | promtail 3.0.0 | |||
| mc 20250813083541 | blackbox_exporter 0.27.0 | vector 0.51.1 | |||
| Kafka 4.0.0 | VictoriaMetrics 1.129.1 | grafana-infinity-ds 3.6.0 | |||
| DuckDB 1.4.2 | VictoriaLogs 1.37.2 | grafana-vmlogs 0.21.4 | |||
| FerretDB 2.7.0 | pg_exporter 1.0.3 | grafana-vmetrics 0.19.6 | |||
| TigerBeetle 0.16.60 | pgbackrest_exporter 0.21.0 | grafana-plugins 12.0.0 | |||
| JuiceFS 1.3.0 | node_exporter 1.10.2 | Utils | |||
| dblab 0.34.2 | keepalived_exporter 1.7.0 | Sealos 5.1.1 | |||
| v2ray 5.28.0 | nginx_exporter 1.5.1 | rclone 1.71.2 | |||
| pig 0.7.2 | zfs_exporter 3.8.1 | restic 0.18.1 | |||
| vip-manager 4.0.0 | mysqld_exporter 0.18.0 | mtail 3.0.8 | |||
| pev2 1.17.0 | redis_exporter 1.80.0 | genai-toolbox 0.18.0 | |||
| promscale 0.17.0 | kafka_exporter 1.9.0 | sqlcmd 1.8.0 | |||
| pgschema 1.4.2 | mongodb_exporter 0.47.1 |








