CremindStorage
Cremind's storage layer — SQLite with Alembic migrations by default, and pluggable Postgres, Qdrant, or ChromaDB when you need to scale.
Cremind's storage philosophy is "start simple, grow when you need to." Out of the box it keeps everything in SQLite on disk, with schema migrations managed by Alembic — nothing external to stand up. When a service outgrows that, you switch just that service to a heavier backend from the Setup Wizard, without re-plumbing the rest.
The default: SQLite + Alembic
A fresh install stores its data in SQLite. This covers configuration, conversations, profiles, and per-tool settings. Schema changes ship as Alembic migrations, which run as part of install and upgrade so your database stays in step with the code.
Because the default is a local file, there are no sidecar containers or external endpoints to manage to get started — the assistant runs end to end on SQLite alone.
Dynamic configuration lives in SQLite and overrides the TOML defaults in app/config/settings.toml. This is how the Setup Wizard's choices — including LLM model groups — take effect at runtime. See LLM Model Groups.
Pluggable backends
Cremind's storage is service-pluggable: you can move an individual concern off SQLite onto a backend built for it.
| Backend | Good for |
|---|---|
| SQLite | The default — relational config, conversations, and settings on a local file. |
| Postgres | A relational backend when you want a real database server. |
| Qdrant | A dedicated vector store for embeddings and retrieval. |
| ChromaDB | An alternative vector store for embeddings. |
You choose these in the Setup Wizard, and you can run them either as Docker sidecars managed alongside Cremind or as external endpoints you already operate.
Where the vector stores fit
Qdrant and ChromaDB are vector stores — they hold the embeddings behind retrieval. That's the layer Document RAG indexes each document's description into, and the layer per-profile embeddings live in. Swapping the vector backend changes where those embeddings are stored without changing how indexing or documentation_search behaves.
Choosing a backend
A useful rule of thumb:
- Just getting started, or a personal single-user install? Stay on SQLite. It's the least to operate and it's the default for a reason.
- Want a managed database server, or multiple processes sharing data? Move the relational store to Postgres.
- Pushing a lot of documents or embeddings through retrieval? Move the vector store to Qdrant or ChromaDB.
You don't have to decide everything up front. Switch one service when you actually feel the need — the rest stays on SQLite.
Cremind is version 0.0.1. Before migrating an existing install to a new backend, back up your data — this is early, community-driven software and backend migration tooling is still maturing.