You can review an engineer's schema well without knowing SQL by checking five things: the entities match how the business actually talks about the domain, the cardinality between them is correct, required fields are enforced with NOT NULL, history is captured instead of overwritten, and the schema can answer the product questions you'll be asked in six months.
Quick answer: A PM reviews a schema by checking five things — right entities, correct cardinality, enforced required fields, captured history, and answerable product questions. You're validating the model against reality, not grading SQL syntax.
What "Reviewing a Schema" Actually Means When You're Not Writing the Migration
Reviewing a schema as a PM means checking that the data model matches how the business actually works, not checking whether the SQL is well-formed. You're validating entities, relationships, and constraints against reality — a modeling review, not a code review. Engineers own the implementation; you own whether the model is true.
Most PMs freeze the moment a schema diagram shows up in a pull request. Boxes, arrows, VARCHAR(255) — it reads like implementation detail, somebody else's job. It isn't. A schema is a formal statement of what your product believes exists in the world: what belongs to what, what's optional, and what's never allowed to be missing. Get that wrong, and every feature built on top inherits the mistake.
Martin Kleppmann's Designing Data-Intensive Applications frames a schema as a compatibility contract between everyone who reads and writes that data over the system's life — not a one-time table layout. Reviewing it well means asking whether the contract matches the product's reality, not whether the naming convention is idiomatic.
That reframing matters for how you show up in the review. You're not auditing the engineer's competence. You're the person who knows that a Subscription can pause without cancelling, or that a single Account sometimes has two active owners mid-handoff. The engineer had no way to know that unless someone told them — and that someone is usually you.
A good review session tends to surface three kinds of gaps:
- Missing business rules the engineer had no way to infer from the ticket
- Ambiguous terms that mean different things to sales, support, and engineering
- Edge cases nobody wrote down because they felt too obvious to mention
If the vocabulary here — entities, cardinality, normalization — still feels shaky, our data modeling complete guide covers the fundamentals in plain language before you sit down with the engineer.
The Three Questions That Catch Most Design Gaps
Three questions catch the large majority of costly schema mistakes: are these the right entities, is the cardinality between them correct, and are the fields the product treats as mandatory actually enforced as NOT NULL. Ask these three before anything else — they surface the expensive problems early, while they're still cheap to fix.
This ordering isn't arbitrary. Barry Boehm's long-cited research on software cost curves found that defects caught during design cost an order of magnitude less to fix than the same defects caught after release. Entity and constraint mistakes are exactly the kind that hide quietly until a migration forces them into the open.
- Are these the right entities? Does each table represent one real concept your team already has a name for, or has something been merged or split incorrectly?
- Is the cardinality correct? Can the relationship represent every real scenario the product needs — including the ones that only happen occasionally?
- Are required fields actually required? Is anything the product treats as mandatory left nullable "for now"?
| Question | What It Catches | Example Red Flag |
|---|---|---|
| Are these the right entities? | Missing or collapsed concepts that force a painful migration later | Customer and Account merged into one table, but enterprise customers need several accounts under one customer |
| Is the cardinality correct? | Relationships that quietly can't represent real usage | A User-to-Team foreign key allows only one team, but the product lets people join several |
Are required fields NOT NULL? | Data integrity gaps that surface as bugs months later | email is nullable "temporarily," so half your reporting queries silently drop rows |
If you only have ten minutes before a schema ships, spend all ten on these three questions. Everything else — indexing, naming, normalization form — is refinement you can revisit later without breaking the product.
The Full PM Schema Review Checklist
Beyond the three highest-leverage questions, a complete review works through five categories: entities and boundaries, cardinality, constraints, history and auditability, and whether the schema can answer the questions your roadmap will actually ask. Each category has a small, concrete set of things to check — none of them require writing a query.
Before the review meeting, sketch your own version of the entity-relationship diagram, even roughly, on paper or a whiteboard. Our piece on why the data model is the product makes this case directly: a PM who has drawn the boxes and arrows once asks sharper, more specific questions than one who has only read the ticket.
Entities and Boundaries
- Does every table map to a real noun your team already talks about in standups and specs?
- Is a concept hiding inside a status column, a JSON blob, or a boolean flag instead of being its own entity?
- Would two different teams — say, support and billing — draw this same boundary the same way?
When the answer is unclear, our guide on what counts as an entity has a concrete test you can apply in the moment rather than relying on intuition alone.
Cardinality: Does the Relationship Match Reality?
| Relationship Type | Question to Ask | Common Mistake |
|---|---|---|
| One-to-one | Will this ever legitimately become one-to-many? | Treating a User and their Profile as permanently 1:1, then needing multiple profiles per user later |
| One-to-many | Is the "many" side ever actually zero, or ever actually more-than-expected? | An Order assumed to have exactly one Invoice, breaking on partial refunds or split billing |
| Many-to-many | Is there a join table, or has the relationship been flattened onto one side? | A Product storing a single CategoryID instead of a join table, blocking multi-category tagging |
Cardinality mistakes rarely show up in the demo. They show up eight months later, in the one account that behaves differently — the enterprise customer with three billing entities, the user who somehow joined two teams.
Required Fields and Constraints
Ask the engineer, plainly: "Which fields can the application logic actually leave empty, and does the schema enforce that same rule?" Constraints exist so that no future code path — including one written by someone who never read today's spec — can violate the rule.
- Is every field the product treats as mandatory enforced with
NOT NULL, not just validated in the frontend? - Does anything that must be one-of-a-kind (an email, a slug, an external ID) have a
UNIQUEconstraint? - What happens on
ON DELETEfor foreign keys — does deleting a parent record cascade, restrict, or orphan children silently? - Are there sensible defaults, or does "no value yet" quietly become
NULL,0, or an empty string with three different meanings depending on which engineer wrote the query?
History and Auditability
Does the schema capture what happened over time, or only the current state? Overwriting a status field in place means you can never answer "how long did this sit in review" or "what did this look like last Tuesday" — questions that come up in nearly every retro and postmortem.
Ralph Kimball's work on slowly changing dimensions, foundational in data warehousing, exists precisely because "current state only" schemas can't support the historical questions the business eventually asks. At minimum, check for created_at and updated_at on anything the product will report on, and consider whether state changes need their own event log rather than a single mutable column.
This is also where the delete strategy matters. Our comparison of soft delete versus hard delete walks through when a deleted_at timestamp is worth the added query complexity — usually anywhere compliance, support, or analytics will eventually ask "what did we have before it disappeared."
Can We Answer the Product's Questions?
List the five questions you're most likely to be asked by leadership, support, or an analyst in the next two quarters, then check whether the current schema can answer each one without a migration. If you can't name those five questions yet, that's the actual gap — not the schema.
The jobs-to-be-done framework is useful here precisely because it forces you to state the job the data needs to do, not just the fields it needs to hold. Similarly, mapping the stages in your customer journey tends to reveal timestamps and state transitions nobody thought to capture — the moment of first activation, the moment of churn risk, the moment support escalated.
How to Run the Conversation Without Sounding Like an Audit
The best schema reviews sound like a design conversation about the product, not a correctness check on someone else's code. Ask about scenarios and edge cases instead of asserting what's wrong — the engineer usually reaches the same conclusion faster when the question comes from the product side, not the syntax side.
| Instead of Saying | Ask Instead |
|---|---|
| "This should be a separate table." | "Walk me through what happens when a customer needs two of these at once — does the model support that?" |
| "Why isn't this NOT NULL?" | "Is there a real scenario where this field is legitimately empty, or is 'temporarily nullable' standing in for 'we're not sure yet'?" |
| "You need a history table." | "If support asks what this looked like last week, can we answer that today?" |
| "This foreign key is wrong." | "What's supposed to happen to the children when we delete the parent — keep, cascade, or block it?" |
Bring specific scenarios, not abstractions. "What if an enterprise customer needs three billing contacts" lands better than "is this properly normalized" — it's concrete, it's product-grounded, and it doesn't require the engineer to translate your question into their domain before answering it.
Schema Smells You Can Spot in Five Minutes
You don't need query access to notice most red flags — they're visible in the table and column names themselves, in a migration file or a diagram shared in a design doc. Look for these before the meeting, then bring them as questions rather than verdicts.
- A generic
typeorstatuscolumn with no accompanying history — one mutable field is standing in for a whole timeline - Nullable columns on anything the product copy calls "required"
- No join table where the product clearly allows a many-to-many relationship (a user with multiple roles, a product in multiple categories)
- Boolean flags multiplying (
is_active,is_archived,is_deleted) instead of one clear state field or an event log - No
created_at/updated_aton entities that will ever appear in a report, funnel, or cohort analysis - IDs reused across contexts — the same "ID" field meaning different things depending on which table references it
- Hard deletes on anything a support agent, auditor, or analyst might need to reference after the fact
Bring a Reference Model to the Review, Not Just Questions
The single best preparation for a schema review is having sketched your own version of the model first — even a rough one drawn from the product requirements, before you've seen the engineer's proposal. A reference point turns vague unease ("something feels off") into a specific, answerable question ("I had Team and Workspace as separate entities — why did you collapse them?").
Prodinja's Data Modelling tool is built for exactly this moment: it walks you through sketching entities and relationships from your product requirements and turns that sketch into SQL DDL, giving you a concrete artifact to hold up against the engineer's proposal. You're not trying to out-design the database — you're giving yourself something specific to compare, so the conversation starts from "here's where our models differ" instead of "let me look this over."
That's the honest use case: a comparison tool for the review, not a replacement for the engineer who actually owns the implementation.
Key Takeaways
- Reviewing a schema means validating that it matches business reality, not checking SQL syntax — that's the engineer's job, and yours is different, not lesser.
- The three highest-leverage questions are: are these the right entities, is the cardinality correct, and are required fields actually enforced as
NOT NULL. - History matters as much as current state — if the schema can't say what something looked like last week, plan for that gap now, not after the first postmortem.
- Frame every question around a concrete product scenario ("what happens when...") rather than an abstract modeling principle — it gets a faster, clearer answer.
- Schema smells like nullable "required" fields, missing join tables, and hard deletes are visible without running a single query.
- Sketching your own reference model before the review — on a whiteboard, in an ERD tool, or in a purpose-built modeling tool — gives you something concrete to compare against, not just a vague feeling that something's off.
Frequently Asked Questions
What questions should a PM ask about a database schema?
Start with the three highest-leverage questions: are these the right entities, is the cardinality between them correct, and are the fields the product treats as mandatory enforced with NOT NULL. From there, ask whether history is captured and whether the schema can answer the specific questions your roadmap and reporting will need in the next two quarters.
Do I need to know SQL to review a database schema as a product manager?
No — you need to understand entities, relationships, and constraints conceptually, not write queries. A PM's job in a schema review is validating that the model matches business reality; the engineer owns translating that model into correct, performant SQL. Reading a diagram and asking scenario-based questions gets you most of the value.
How do I know if a schema's cardinality is correct?
Test it against real scenarios, especially uncommon ones: can a customer have more than one billing account, can a user belong to more than one team, can an order have more than one invoice. If any real scenario your product allows can't be represented by the relationship as drawn, the cardinality is wrong, regardless of how clean the diagram looks.
What's the difference between a schema review and a code review?
A code review checks whether the implementation is correct, efficient, and maintainable — indentation, query performance, naming conventions. A schema review checks whether the model itself is true to the business — whether the entities, relationships, and constraints reflect how the product actually needs to behave, which is a product question more than a coding one.
Why does it matter if required fields aren't marked NOT NULL?
Because frontend validation alone doesn't protect the data — any script, migration, admin tool, or future engineer who writes directly to that table can leave the field empty unless the database itself enforces the rule. A field the product treats as mandatory but that's nullable in the schema is a gap waiting for the one code path nobody tested.