SignalJuly 12, 2026

pgvector is optional, not the system of record

Alex OS's semantic retrieval uses an optional Postgres/pgvector store — the CMS itself never left MySQL.

Content

Alex OS reads database_url for an optional Postgres connection with pgvector installed. When it's empty or unreachable, vectordb.py wraps every call in VectorDBError and retrieval.py falls back to keyword scoring instead of failing the request. I built it this way because I didn't want Alex OS's uptime to depend on a second database being healthy — the assistant should degrade to worse answers, not go down.

The CMS itself never moved off MySQL. It's easy to describe this as "the pgvector migration" in shorthand, but that overstates it — nothing about the CMS's system of record changed. Only Alex OS's embeddings store is Postgres, and only when configured.

pgvectorarchitecturealex-os

Internal Links

Keep exploring

ThinkingChanged ThinkingWhy Alex OS is not a chatbotGrounding-over-chat framing informed by the fallback design.ProjectProducedAlex OSDiscovery made while building/describing the project.

Explore with Alex OS

Alex OS's pgvector store is an optional add-on — the CMS stayed on MySQL, and the assistant degrades gracefully when Postgres isn't available.

What actually changed (and what didn't)

The shorthand 'pgvector migration' overstates it. Alex OS now reads a `database_url` env var to connect an optional Postgres/pgvector store for semantic retrieval. The CMS system of record never left MySQL. Only the embeddings layer is Postgres — and only when configured.

Why it's built to be optional

When `database_url` is empty or unreachable, `vectordb.py` raises `VectorDBError` and `retrieval.py` falls back to keyword scoring instead of failing the request. The design goal: Alex OS's uptime shouldn't depend on a second database being healthy. Worse answers are acceptable; downtime isn't.