How software works · Guide for product managers

Databases for product managers

Your product's database is its long-term memory. Every feature decision — what users can filter, what reports are possible, what is expensive to change later — is shaped by how the data is stored. This guide gives you the mental model engineers use, without asking you to become one.

Guide 3 of 10 in the technical PM path

11 min read · Updated 25 September 2026 · By the TechPMer team

Why a PM should care

Screens are easy to change. Data is not. Once real users have created millions of records in a certain shape, changing that shape takes planning, migrations and risk. That is why database decisions deserve product attention early:

• Reporting and analytics only work if the data you need was stored in the first place.
• Performance of search, filters and dashboards depends on how data is organised and indexed.
• Privacy and compliance — what personal data you keep, where and for how long — live in the database.
• Estimates jump when a feature needs a new relationship between things ("a task can now belong to several projects").

The mental model: tables, rows and columns

A relational database looks a lot like a set of spreadsheets that know about each other.

• A table holds one kind of thing: users, projects, tasks.
• A row is one item: one user, one project.
• A column is one attribute: email, created_at, status.
• Every row has a unique primary key (an ID) so it can be referenced reliably.

users                              projects
id | email         | plan          id | name             | owner_id
---+---------------+------         ---+------------------+---------
 1 | ana@acme.com  | pro            7 | Website relaunch | 1
 2 | ben@acme.com  | free           8 | Q4 roadmap       | 1

owner_id in projects points to id in users. That pointer is a foreign key, and it is how the database knows project 7 belongs to Ana.

Relationships (where most estimates hide)

A classic source of surprise: a feature request that turns a one-to-many into a many-to-many ("a task can be in several projects"). It sounds like a small UI change; underneath it can mean a new table, a data migration and changes to every query that reads tasks.

SQL: the language of relational databases

SQL (Structured Query Language) is how you ask a relational database questions. You do not need to write it daily, but reading a simple query is a superpower for a PM:

SELECT plan, COUNT(*) AS users
FROM users
WHERE created_at >= '2026-09-01'
GROUP BY plan;

In words: "How many users signed up since 1 September, per plan?" Many analytics tools and AI assistants will write SQL for you — reading it lets you check that it answers the question you actually asked.

SQL vs NoSQL

Relational (SQL) databases — PostgreSQL, MySQL, SQL Server — store data in tables with a defined structure (a schema) and enforce relationships. They are the default choice for most business applications.

NoSQL databases are a family, not one thing: document stores (MongoDB, Firebase Firestore), key-value stores (Redis), wide-column and graph databases. Document databases store flexible JSON-like documents and scale reads very well, but you often duplicate data and design around the exact screens you need.

The honest summary: choose based on access patterns and the team's experience, not on fashion. Many successful products run on a single PostgreSQL database for years.

Indexes: why some queries are fast

An index is like the index at the back of a book: instead of reading every page to find "migration", you jump straight to the right pages. Without an index the database may scan every row — fine for 1,000 rows, painful for 50 million.

Indexes are not free: they use storage and slow down writes slightly. That is why engineers add them for the queries that matter. When a filter or search is slow, "is there an index for this query?" is a great question.

Migrations: changing the shape of data safely

A migration is a versioned script that changes the database structure — add a column, split a table, backfill data — in a controlled, repeatable way.

When an engineer says "we need a migration before we can release this", they mean the database must change first, and that change has to be run safely on real production data. Migrations can involve:

• Backfilling existing rows (every old user needs a value for the new column).
• Downtime or locking risks on large tables.
• Ordering with the release: new code must work with both the old and new shape during the rollout.

This is why "just add a field" is sometimes a one-hour change and sometimes a one-week one.

Transactions and data integrity

A transaction groups several changes so they succeed or fail together. Moving money between two accounts must debit one and credit the other — never only one. Databases also enforce constraints: unique emails, required fields, valid references. These rules protect you from whole categories of bugs, so removing them "to make it work" is a red flag.

Backups, environments and personal data

• Backups — how often, how long they are kept, and whether anyone has actually tested restoring one.
• Environments — development, staging and production usually have separate databases. Real customer data should not be copied into development casually.
• Personal data — know which tables hold it, who can access it and how a user's data is deleted when they ask.

What engineers may tell you

• "That's an N+1 query." The code runs one query per item in a list (101 queries for 100 items) instead of one; it gets slow as data grows.
• "We need to denormalise this for performance." Store a copy of data in a second place to make reads faster, at the cost of keeping copies in sync.
• "The migration will lock the table." While it runs, writes to that table may be blocked — plan a maintenance window or a safer approach.
• "It's eventually consistent." After a change, other parts of the system may show the old value for a short time.
• "We should soft-delete it." Mark a record as deleted instead of removing it, so it can be restored or audited.

Questions a good technical PM asks

1. What new tables, columns or relationships does this feature need?
2. Does it need a migration or backfill? Can it be released without downtime?
3. Which queries will be most frequent, and are they indexed?
4. What personal data are we storing, and how is it deleted?
5. What happens to related data when something is deleted?
6. How would we report on this feature's usage later?

Red flags

• "We'll just store it as one big text/JSON field and figure it out later" for data you will filter or report on.
• No one knows when the last backup restore was tested.
• Production data copied to laptops or shared test environments.
• Database rules (unique, required) removed to make an error go away.
• A delete that silently removes everything related to it, with no confirmation or recovery.

Using an AI coding agent with databases

AI agents write schemas and queries quickly — and happily create a new table for every screen. Before you let one touch your data:

• Ask it to propose the data model first (tables, fields, relationships) and explain it in plain language before writing code.
• Require migrations instead of manual changes, so every change is versioned in Git.
• State security rules explicitly — for example, "users can only read and write their own documents" — and ask it to write tests or rules that enforce them.
• Never paste production credentials into the chat; use environment variables.

Try it yourself

Take one screen from your product and list the data it shows. For each item, ask: which table (or collection) does this come from, and how is it connected to the others? Sketching that on paper — boxes for tables, lines for relationships — is the exact skill engineers use when they design a data model.

In the TechPMer course, week 7 (“Data & User Accounts”) walks you through designing, storing and securing your own project's data with an AI coding agent.