Summary
ghcr.io/pgedge/coldfront-duckdb-base is published amd64-only (a single
application/vnd.docker.distribution.manifest.v2+json manifest). It is the
only image in the pgEdge org that is not multi-arch — every other product
image ships a multi-arch index with native linux/amd64 + linux/arm64. As a
result, the ColdFront stack runs under emulation on Apple Silicon (and any
arm64 host), which is functional but materially slower.
Evidence
Published tags pg16, pg17, pg18 are each a single-arch manifest:
$ docker buildx imagetools inspect ghcr.io/pgedge/coldfront-duckdb-base:pg18
MediaType: application/vnd.docker.distribution.manifest.v2+json # single manifest, not an index
# config blob: architecture: amd64, os: linux
Every other pgEdge product image is multi-arch (amd64 + arm64):
| Image |
arches |
pgedge-postgres (18-spock5-minimal) |
amd64 + arm64 |
| control-plane |
amd64 + arm64 |
| ai-dba-server / ai-dba-collector |
amd64 + arm64 |
| postgres-mcp |
amd64 + arm64 |
| ace |
amd64 + arm64 |
| rag-server |
amd64 + arm64 |
| postgrest |
amd64 + arm64 |
| nla-web |
amd64 + arm64 |
| cloudnative-pg |
amd64 + arm64 |
| plugin-barman-cloud |
amd64 + arm64 |
| coldfront-duckdb-base |
amd64 only |
Why this is straightforward to fix
coldfront-duckdb-base is built FROM ghcr.io/pgedge/pgedge-postgres:<pg>-spock5-minimal, which already has a native arm64 build — the arm64 foundation exists..github/workflows/base-image.yml already supports arch=arm64 on native ubuntu-24.04-arm runners. It has simply never been run with arch=arm64 push=true.
Proposed fix
- Build + push the arm64 bases: run
base-image.yml with arch=arm64 pg=all push=true (produces pg{16,17,18}-arm64).
- Publish a multi-arch manifest list for the bare
pg<major> tags so they resolve natively on both arches (e.g. docker buildx imagetools create -t …:pg18 …:pg18-amd64 …:pg18-arm64), and update base-image.yml to do this as part of a normal publish.
- Verify:
docker manifest inspect ghcr.io/pgedge/coldfront-duckdb-base:pg18 shows both amd64 and arm64.
Related (separate gap, for tracking)
ColdFront also has no APT or DNF packages published in the pgEdge Enterprise
repos (apt.pgedge.com / dnf.pgedge.com) on any architecture, while every
other beta product is present (and ships aarch64). Likely the same
beta-launch packaging miss; worth a separate issue with the release owners.
Summary
ghcr.io/pgedge/coldfront-duckdb-baseis published amd64-only (a singleapplication/vnd.docker.distribution.manifest.v2+jsonmanifest). It is theonly image in the pgEdge org that is not multi-arch — every other product
image ships a multi-arch index with native
linux/amd64+linux/arm64. As aresult, the ColdFront stack runs under emulation on Apple Silicon (and any
arm64 host), which is functional but materially slower.
Evidence
Published tags
pg16,pg17,pg18are each a single-arch manifest:Every other pgEdge product image is multi-arch (
amd64+arm64):18-spock5-minimal)Why this is straightforward to fix
coldfront-duckdb-baseis builtFROM ghcr.io/pgedge/pgedge-postgres:<pg>-spock5-minimal, which already has a native arm64 build — the arm64 foundation exists..github/workflows/base-image.ymlalready supportsarch=arm64on nativeubuntu-24.04-armrunners. It has simply never been run witharch=arm64 push=true.Proposed fix
base-image.ymlwitharch=arm64 pg=all push=true(producespg{16,17,18}-arm64).pg<major>tags so they resolve natively on both arches (e.g.docker buildx imagetools create -t …:pg18 …:pg18-amd64 …:pg18-arm64), and updatebase-image.ymlto do this as part of a normal publish.docker manifest inspect ghcr.io/pgedge/coldfront-duckdb-base:pg18shows bothamd64andarm64.Related (separate gap, for tracking)
ColdFront also has no APT or DNF packages published in the pgEdge Enterprise
repos (
apt.pgedge.com/dnf.pgedge.com) on any architecture, while everyother beta product is present (and ships aarch64). Likely the same
beta-launch packaging miss; worth a separate issue with the release owners.