mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 12 Actions Packages Projects Releases 15 Wiki Activity

Decouple memory.type from storage tier: standalone must support pgvector #1398

New Issue
Open
opened 2026-08-24 21:49:19 +00:00 by orch-01 · 2 comments
orch-01 commented 2026-08-24 21:49:19 +00:00
Contributor
Copy Link
Copy Source

The tier concept currently conflates topology (single instance vs federated) with memory capability (keyword vs vector): standalone hard-writes memory.type=keyword and vector memory is reachable only via the federated tier. These are orthogonal. Vector storage is a property of the storage backend, not of how many sites participate: a single-site deployment with its own Postgres running the pgvector image has everything vector memory needs and is denied it only by config validation.

Operator ruling driving this (USC operator, 2026-08-24): even federated instances need their OWN LOCAL vector storage (federation is a sync/query concern above local storage, not a substitute for it), so every tier ends up needing the same local vector capability anyway.

Ask: make memory.type an independent knob (keyword | pgvector) valid on standalone and federated alike, with a pgvector-extension preflight where selected.

Evidence base: T63 greenfield (see 1389/1393 context): standalone install on a pgvector-image Postgres, memory silently keyword.

Reported by usc/fred during T63 greenfield deployment. Filed by orch-01. Tag: T63.

The tier concept currently conflates topology (single instance vs federated) with memory capability (keyword vs vector): standalone hard-writes memory.type=keyword and vector memory is reachable only via the federated tier. These are orthogonal. Vector storage is a property of the storage backend, not of how many sites participate: a single-site deployment with its own Postgres running the pgvector image has everything vector memory needs and is denied it only by config validation. Operator ruling driving this (USC operator, 2026-08-24): even federated instances need their OWN LOCAL vector storage (federation is a sync/query concern above local storage, not a substitute for it), so every tier ends up needing the same local vector capability anyway. Ask: make memory.type an independent knob (keyword | pgvector) valid on standalone and federated alike, with a pgvector-extension preflight where selected. Evidence base: T63 greenfield (see 1389/1393 context): standalone install on a pgvector-image Postgres, memory silently keyword. Reported by usc/fred during T63 greenfield deployment. Filed by orch-01. Tag: T63.
orch-01 commented 2026-08-24 21:59:59 +00:00
Author
Contributor
Copy Link
Copy Source

Operator ruling update: homelab operator (Jason, 2026-08-24) CONCURS with the USC operator ruling. Joint operator backing: memory.type becomes an independent knob (keyword | pgvector) valid on standalone and federated tiers alike, with a pgvector-extension preflight where selected. Design proceeds on that basis.

Operator ruling update: homelab operator (Jason, 2026-08-24) CONCURS with the USC operator ruling. Joint operator backing: memory.type becomes an independent knob (keyword | pgvector) valid on standalone and federated tiers alike, with a pgvector-extension preflight where selected. Design proceeds on that basis.
orch-01 commented 2026-08-24 22:37:08 +00:00
Author
Contributor
Copy Link
Copy Source

Additional evidence (USC web1, 2026-08-24, relayed by orch-01): standalone with memory.type=keyword still initializes EmbeddingService, which WARNs 'Embedding dimensions (768) differ from pgvector schema (1536)' on every start. Two implications for the decoupling work: (1) the embedding path is not actually gated off on keyword tiers, so the tier/memory conflation already leaks at runtime; (2) the schema hard-codes vector(1536) while the embedder produces 768 - the pgvector knob needs a dimension config (or schema derived from the embedder) as part of this change, not a fixed 1536.

Additional evidence (USC web1, 2026-08-24, relayed by orch-01): standalone with memory.type=keyword still initializes EmbeddingService, which WARNs 'Embedding dimensions (768) differ from pgvector schema (1536)' on every start. Two implications for the decoupling work: (1) the embedding path is not actually gated off on keyword tiers, so the tier/memory conflation already leaks at runtime; (2) the schema hard-codes vector(1536) while the embedder produces 768 - the pgvector knob needs a dimension config (or schema derived from the embedder) as part of this change, not a fixed 1536.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-infra-01 (Mosaic fleet seat code-infra-01) fargo fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) pepper rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) sanity scooby (Scooby) scrappy shaggy tiny velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1398