Postgres vs MySQL vs MongoDB

Database choice.

Overview

Postgres, MySQL, and MongoDB are the three databases most production stacks pick from. Postgres leads on rich relational features (JSONB, CTEs, window functions, extensions); MySQL leads on simpler operations (broad managed-service support, simpler replication); MongoDB leads on document-first workloads (variable schema, native aggregation pipelines). Picking the right one at design time avoids the migration that costs an engineer-quarter at year three.

• Postgres: rich relational features. JSONB, CTEs, window functions, extensions like PostGIS. Default for query-heavy applications.
• MySQL: simpler operations. Broad managed-service support across clouds, simpler replication setup. Default when ops simplicity matters.
• MongoDB: document-first. Variable schema, native aggregation pipelines, JSON-shaped data. Default for catalogue, content, application data.
• Per-database choice. Different databases may pick differently. Document the rationale per database rather than enforcing one engine across all of them.

The approach

Workload-driven choice, per-team operational fit considered, documented rationale per database. The discipline is matching the engine to the workload's access patterns rather than picking by team familiarity alone, then capturing the reasoning so future investigations have the breadcrumbs.

• Workload-driven. Engine per database. Reality drives the answer.
• Postgres for query-rich workloads. Complex SQL, JSONB, extension needs. Default for greenfield SaaS application data.
• MySQL for ops-simplicity workloads. Broad managed support, simpler replication. Default when ops simplicity dominates.
• MongoDB plus documented rationale. Document-shaped variable-schema data; per-database rationale captured so future migrations have a paper trail.

Why this compounds

The right database choice compounds across years. Wrong choices pay performance or migration penalties indefinitely; right choices pay neither. Cross-database tooling (operational runbooks, capacity planning) gets built once per engine and reused. By year two the choice is automatic per workload.

• Better operational fit. Database matches workload. Velocity stays high.
• Workload-driven decisions. Replaces tribal preference with documented rationale. Quality of choice improves.
• Better engineering velocity. Right database means queries compose cleanly. Iteration speed increases.
• Year-one investment, year-two habit. First decision is the investment; subsequent databases inherit the patterns.