Consumers on postgres:NN-alpine can't switch to the Debian pgvector image
without reindexing every text index (musl vs glibc collation). This builds
pgvector into the same Alpine image instead. Verified on PG 16 and 17.

2026-09-30 00:36:41 -06:00

Dockerfile

Add a tested Postgres Alpine + pgvector Dockerfile

2026-09-30 00:36:41 -06:00

README.md

Add a tested Postgres Alpine + pgvector Dockerfile

2026-09-30 00:36:41 -06:00

README.md

Postgres on Alpine with pgvector

For stacks that already run postgres:NN-alpine and want the vector extension for fastmcp-feedback embeddings.

Why not switch to the pgvector/pgvector image: it's Debian (glibc), and the Alpine images use musl. The two C libraries sort text differently under locales such as en_US.utf8, so reusing an Alpine data directory under a Debian image changes the order of every text index. The indexes need a full REINDEX or they silently return wrong results. Building pgvector into the same Alpine image keeps the data directory's collation unchanged.

docker build --build-arg PG_MAJOR=16 -t postgres-pgvector:16-alpine .
docker build --build-arg PG_MAJOR=17 -t postgres-pgvector:17-alpine .

Then point the stack's Postgres service at the new image (same major version as the existing data directory) and run CREATE EXTENSION IF NOT EXISTS vector; once, or let a migration do it.

Tested 2026-09-30 with pgvector v0.8.6 on postgres:16-alpine and postgres:17-alpine: the extension loads, and an HNSW vector_cosine_ops index is used for ORDER BY embedding <=> ... queries.

with_llvm=no skips the LLVM bitcode used for JIT inlining. The base images' Postgres was built with a clang version Alpine no longer ships, so the bitcode step fails; pgvector itself still builds with gcc and works normally.