Managed pgvector: hold until 3+ apps want it — it is a different image, not a Postgres version

[onel]

Size

M

Area

backend

Depends on

none (follows #354, which added Postgres 17/18 and documented the extension split)

Summary

Postgres extensions that are not in the official postgres image — pgvector first, postgis/timescaledb behind it — cannot be reached from a managed services: block at all, no matter what an app's credential is allowed to do. Offering one means a distinct managed type backed by a different image (pgvector/pgvector:pg18), not a new version. This issue holds that decision until the bar is met; it is deliberately not actionable yet.

Spec / source of truth

docs/specs/SERVICE_PROVISIONING.md # Database extensions (added by #354) and # Catalog (v1) — specifically the "we add new types when 3+ store apps actually want them" rule.

Do

Nothing until the bar is met. When it is:

1. Decide type-vs-flavour: a type: pgvector entry in serviceVersions (internal/manifest/manifest.go) versus an image swap on the existing postgres type. A separate type means a separate shared container and data dir; an image swap on postgres would migrate every existing instance onto a different image, which is not free.
2. internal/lifecycle/services.go — serviceImageRepo and the compose template. The pgvector/pgvector:pg<major> tag scheme is not <version>, so the current repo + ":" + version construction does not cover it as-is. PGDATA needs the same pin Managed Postgres: add a current major (18) — and fix the hardcoded PGDATA bind that would silently eat its data #354 applied (the pgvector images track the upstream layout, including 18's move).
3. Decide whether the brain runs CREATE EXTENSION vector at provisioning time or leaves it to the app. It is untrusted, so the app's own role cannot — which is the whole reason this needs platform involvement rather than being a manifest detail.
4. A dockerlive test in the shape of TestLivePostgres18Persistence: provision, create a vector column, destroy the container, reconcile back, assert the data survived.
5. Update SERVICE_PROVISIONING.md # Catalog (v1) + # Database extensions and APP_MANIFEST.md # D in the same PR.

Touch

internal/manifest/manifest.go, internal/lifecycle/services.go, internal/lifecycle/dockerlive_test.go, docs/specs/SERVICE_PROVISIONING.md, docs/specs/APP_MANIFEST.md

Done when

Either 3+ store apps actually want a vector-capable Postgres and it ships as a managed type with the live durability test green — or the bar is judged unlikely to be met and this issue is closed with the "bundle your own engine" path recorded as the answer. Until one of those, this issue stays open and untouched; apps needing pgvector bundle their own engine, which is already the documented path.