2.2.1Start with a relational database
The default for almost every app is a relational database, also called SQL after the language you query it with. It keeps your data in tables of rows and columns with clear links between them, the same shape you drew when you sketched your data model.
This is the right choice unless you have a specific reason it is not, and most apps never do. Your stack already pointed you at PostgreSQL, a proven, free relational database that handles almost anything you give it.
2.2.2Know the other kinds and when they fit
A few other kinds exist, each shaped for data that tables handle awkwardly. You will rarely need them, but you should know the names and what each is for.
| Kind | What it holds | Use it when |
|---|---|---|
| Relational (SQL) | Tables with clear relationships | Almost anything, your default |
| Document (NoSQL) | Loose records of varied shape | Records differ from one to the next |
| Key-value | One value fetched by its key | Fast, simple, repeated lookups |
| Vector | Data indexed by meaning | AI search by similarity |
| Graph database | Data made of connections | Social graphs, recommendations, fraud rings |
The last one, vector, only comes up when you add AI search over your own content, matching by meaning instead of exact words. That is a specific, later need, not something a first version carries.
Beyond these sit more specialized kinds still, like time-series stores built for metrics and events over time, each the right tool for one specific job. Knowing the whole menu lets you choose deliberately for a real system, but it is not a reason to run several at once.
One thing never belongs in a database at all: files and media (user uploads, images, documents, video). Those go in object storage, an S3-style store with self-hosted options too, while your database keeps only a link to each file.
2.2.3One database is usually enough
It is tempting to reach for several kinds at once, a cache for speed (a fast store for repeat answers) and a document store for varied data. Resist it. Every extra database is another moving part to run and keep in sync, and it multiplies the work of everything built on top.
Start with one relational database and let it do the whole job, which it can for far longer than you would guess. Add a second kind only when a real need appears: a page too slow without a cache, or an AI feature needing vector search. Never add one on a hunch that you might want it later.
Even that vector search rarely needs a separate store, because a relational database like Postgres can do it through an extension (pgvector), keeping you on one database instead of adding another.
2.2.4Let your agent pick for your data
You have the default and the handful of exceptions, so hand the real call to your agent. Give it the data you sketched and what the app must do, and have it name the kind, defaulting to one relational database and justifying anything more.
This prompt already carries the judgment. Paste it in and describe your app in the single slot at the bottom:
Do this now: keep the relational default your stack already gave you, or paste the prompt, describe what your app stores, and lock in one kind of database before the next chapter.
