Relational vs non-relational databases: a working guide for product managers

Engineers love this debate. Product managers should mostly stay out of it. The choice between a relational and non-relational database is one of the few technical decisions where the right answer is usually visible from the requirements doc, and where being opinionated about the wrong details slows the team down.

This is the working guide we hand to product managers and non-technical founders when the question comes up.

What “relational” actually means

A relational database stores data in tables with defined columns and types, and enforces relationships between tables (foreign keys, joins). The defining feature is that the database knows what shape your data is supposed to take and refuses to accept data that does not fit. Most also support transactions: a group of changes either all succeed or all fail.

Examples: PostgreSQL, SQL Server, MySQL, Azure SQL Database, Amazon Aurora.

What “non-relational” means

Non-relational covers a few different shapes, but the common thread is that the database does not enforce a schema. You can store one record with five fields and another with twelve fields and the database will not complain. Different families serve different needs:

• Document stores (MongoDB, Cosmos DB document API). Hold JSON-like documents. Good for nested or hierarchical data.
• Key-value stores (Redis, DynamoDB). Hold a value indexed by a key. Very fast for simple lookups.
• Wide-column stores (Cassandra, Cosmos DB Cassandra API). Hold rows with arbitrary columns. Good for high write throughput at scale.
• Graph databases (Neo4j, Cosmos DB Gremlin API). Hold nodes and edges. Good for relationships between things, where the relationships matter as much as the things.

The PM heuristic

If you can describe your data as a set of tables with rows and columns, use a relational database. That is the heuristic. It covers the majority of mid-market business applications.

The exceptions, in roughly the order we see them:

• Hierarchical or nested data with no fixed shape. Configuration documents, product catalogs where every product type has different attributes, content management systems. Document stores fit.
• Sub-millisecond lookup requirements at high volume. Session storage, leaderboards, real-time caching. Key-value stores fit.
• Logs, metrics, telemetry, time-series data. Specialized time-series databases (InfluxDB, TimescaleDB, Azure Data Explorer) fit, though Postgres with TimescaleDB extension covers most cases.
• Relationships are the data. Recommendation engines, fraud detection, social graphs. Graph databases fit.

If your application does not match one of those, the answer is a relational database. The “scale” objection (the database will not scale) is real for a few percent of applications and false for everyone else. PostgreSQL and SQL Server both handle terabytes and tens of thousands of concurrent users without architectural heroics.

The middle ground

Modern relational databases blur the line. Postgres has had JSONB for over a decade. SQL Server has JSON columns. You can store a structured document inside a relational column, query it natively, and get the benefits of both: the strict schema for the parts of your data that have one, and the flexible document for the parts that do not.

This is the right answer for a surprisingly large share of “we need NoSQL because our schema changes a lot” cases. It is also the answer that often does not get suggested, because it is less interesting to talk about than a multi-database architecture.

What to ask your engineering team

The most useful questions a PM can ask when this debate comes up:

• What does the team have most experience operating? A familiar database the team can run well usually beats a more theoretically appropriate one the team is learning.
• What are the real query patterns? Not the imagined ones from the requirements doc. The actual reads and writes the application will do.
• Where does the data need to live in three years? Migrating between database types is expensive. Picking one you can grow into is worth a small upfront cost.

The right answer is usually the boring one. Pick a relational database your team knows, store the structured part as columns and the flexible part as JSON, and revisit the architecture only when measured load tells you something is actually wrong.