rsp2k
2bd3d9476c
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.
1.3 KiB
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.