Table of Contents

INTRO

Introduction: The Advice Gap

Most database advice is written for teams running fleets at a scale you'll never hit, or it's a vendor pitch dressed up as a best practice. This book is for the team in the middle — small, shipping, and now bolting AI features onto a product that already has users.

Who this is for (and who it isn't)
What AI features actually changed about your data layer
My bias, stated up front: fewer moving parts beats theoretical scalability
Where the examples come from — real systems, not whiteboard design

Part I: The Defaults

CH 1

The Database Problem Changed

An AI app is not a CRUD app with a chatbot stapled on. The moment you add retrieval, chat history, and embeddings, your data layer becomes a small system of parts that each fail differently.

Why "CRUD plus a chatbot" is the wrong mental model
The four dials every feature moves: cost, latency, safety, flexibility
The core categories in plain English: transactional, cache, object storage, search, vector
Five jobs, not five products you must buy

CH 2

Start With a Relational Default

The right first database for almost every team is a boring relational one, and you should resist adding anything specialized until that default visibly stops working.

One relational database until it hurts — and what counts as "hurts"
The "specialized system" tax: backups, auth, monitoring, upgrades, failure modes
SQLite is a real database, not a toy
The JSON column escape hatch for semi-structured data

CH 3

Postgres, MySQL & SQLite in Plain English

These three are the practical defaults. This is the chapter where I commit to recommendations instead of hedging, so you leave with a decision, not a comparison matrix.

One-line gut calls for each, then the justification
Default use cases, real trade-offs, and the scaling path
The honest weaknesses: SQLite's write ceiling, Postgres pooling, MySQL foot-guns
A blunt decision flowchart in prose

Part II: What AI Actually Changes

CH 4

What AI Changes About Data

AI mostly adds new categories of data rather than replacing the database you already have. This chapter is the inventory: each new kind of data, what it's for, and where it should live.

Embeddings, retrieval data, chat history, traces, feedback
What's derived and regenerable vs. what's precious
Why most of it is either derived data or plain append-heavy rows
A concrete map of one real app, data type by data type

CH 5

When Vector Databases Help

Vector search is genuinely useful, and a dedicated vector database is genuinely overkill for most teams reading this. This is the chapter that fights the AI-app hype hardest.

What vector search actually does, and when keyword search is better
pgvector first: one database, one backup story, one thing to secure
The honest ceiling — where pgvector starts to strain
The hidden costs of a separate vector store, and hybrid search reality

CH 6

Caches, Queues & Object Stores

Three jobs your relational database should not be doing alone. Reaching for the right small tool for each is the difference between clean architecture and a Postgres instance you've tortured into being a file server.

Caches: fast, disposable copies — and the rules that keep them from biting you
Queues: from a status-column table to a real broker, and when to graduate
Object storage: never put large binaries in your relational database
One concrete ingestion flow, end to end

Part III: Operations & Reality

CH 7

Security in the AI Age

Secrets management is table stakes — a solved, boring problem — and treating it as the finish line is exactly how small teams get burned. The real risk is insecure data flow.

Credentials and rotation, done right and briefly
Least privilege: the app user should not be able to drop tables
Insecure data flow: PII in logs, embeddings carrying sensitive text out
The AI-specific mistakes: agents pointed at prod with full write access

CH 8

Managed Databases & Cloud Reality

For a small team, a managed database is almost always worth the money. The instinct to self-host to save a few dollars a month is how founders end up doing unpaid, high-stakes ops at the worst possible time.

The real math: buying down operational risk, not convenience
RDS/Aurora and Cloud SQL connection realities and gotchas
When self-hosting is fine — and when it's a bad trade
Backups are the line in the sand: you must be able to restore

Part IV: Recipes & Reference

CH 9

Architecture Recipes

After eight chapters of principles, this is where they get assembled. Short, concrete stacks for the situations small teams actually find themselves in — each a complete starting point, not a buffet.

SaaS app with light AI features: Postgres + Redis + object storage
Internal knowledge tool: the canonical RAG stack on one database
High-ingest event pipeline: relational core + queue + analytical sink
The prototype that should stay simple: SQLite + files

CH 10

Migration Paths

Plenty of readers are already running something and need the next step without breaking what works. Each migration is a known move with a known set of traps, done incrementally.

SQLite → Postgres: the most common graduation, framed as a milestone
Self-hosted → managed, with near-zero-downtime cutover
Keyword → vector-enhanced retrieval, backfilled as a queue job
Never big-bang: run old and new in parallel, always keep a rollback

CH 11

Checklists & Anti-Patterns

The operational cheat sheet — the chapter you'll dog-ear. The whole book condensed into scannable lists: what to use by default, what to avoid, and the concrete signals that it's time to upgrade.

The defaults checklist: what to reach for first
Anti-patterns: the recurring mistakes, named plainly
Upgrade signals: concrete triggers, not vibes
A one-screen summary you could screenshot

Back Matter

Chapter 12: Seth's AI Disclosure

Exactly how this book was written, and where AI helped — stated plainly, no hand-waving.