Blog · Chapter 06 · Database & storage
The right store for every kind of data
Relational, object, vector, graph and telemetry stores, and why "Postgres plus object storage" is the right place to start.
An AI application stores more kinds of data than a classic web application: business records, original files, embeddings, knowledge graphs, conversation state, traces and evaluation results. Chapter 6 maps each to the right store.
Separate concerns
| Data | Store | Why |
|---|---|---|
| Business records, users, runs, approvals | Relational database | Transactions, constraints, reporting |
| Original files, images, audio | Object storage | Cheap, durable, immutable originals |
| Chunks and embeddings for retrieval | Vector index | Similarity search with metadata filters |
| Entities and relationships | Graph (when needed) | Multi-hop questions, GraphRAG |
| Traces, logs, metrics | Telemetry stores | High volume, time-based queries, retention |
Start with "Postgres plus object storage"
PostgreSQL with JSONB, pgvector and full-text search covers relational data, documents, vectors and keyword search in one system, with one backup and one security model. Add object storage for files and Redis for queues and caching. Add specialised stores, such as a dedicated vector database or a graph database, only when measurements show you need them.
Profile the information before you choose
The companion chapter on knowledge management adds an important step: profile how information is laid out in each document type before choosing storage. Is it fragmented across sections, hidden in tables or formatting, contradictory, versioned? Free text belongs in the vector store, exact numbers and dates in relational tables, and relationships in a graph. Most real knowledge bases are hybrid, with stores linked by shared IDs.
Keep originals and lineage
Store originals immutably and keep lineage from file to parsed text, to chunk, to embedding, including the embedding model version. When you change the model or the chunking strategy, you can rebuild the index from the source instead of guessing what was in it.
Access control and retention
- Enforce access control in queries, with metadata filters based on the user's rights, never in prompts.
- Treat traces and logs as sensitive data: they contain prompts, documents and personal data. Give them retention and deletion policies, because the right to erasure applies there too.
Key takeaways
- Relational for transactions, objects for files, vectors for retrieval.
- Store originals immutably; keep lineage to every embedding.
- Enforce access control in queries, never in prompts.