“Should we use MySQL/PostgreSQL or MongoDB?” comes up in almost every new project. SQL (relational) databases and the many kinds of NoSQL databases make different trade-offs around structure, consistency and scaling. The right choice depends on your data and access patterns, not on trends. Here’s a practical comparison.
What “SQL” means
Relational databases store data in tables with rows and columns, linked by keys, and queried with SQL: MySQL, MariaDB, PostgreSQL, SQLite, SQL Server.
- Schema: columns and types are defined up front (changed with migrations).
- Relationships: foreign keys and joins combine data across tables.
- Transactions: ACID guarantees, so multi-row changes either fully happen or not at all.
- Flexible queries: ad-hoc filtering, aggregation and reporting on any column.
What “NoSQL” covers
“NoSQL” is an umbrella for several quite different models:
| Type | Model | Examples | Good at |
|---|---|---|---|
| Document | JSON-like documents | MongoDB, CouchDB | Nested, varying data per record |
| Key-value | Key → value | Redis, Valkey, DynamoDB, etcd | Caching, sessions, counters, very fast lookups |
| Wide-column | Rows with dynamic columns, partitioned | Cassandra, ScyllaDB, HBase | Huge write volumes, time-ordered data across many nodes |
| Graph | Nodes and relationships | Neo4j | Highly connected data, path queries |
| Search | Inverted indexes | Elasticsearch, OpenSearch, Meilisearch | Full-text search, relevance ranking |
| Time-series | Timestamped measurements | InfluxDB, TimescaleDB | Metrics, IoT, monitoring |
| Vector | Embeddings | Qdrant, Milvus, pgvector | Similarity search, AI and RAG |
See MongoDB, Redis, Neo4j, time-series databases and vector databases.
Key differences
| SQL (relational) | NoSQL (typical) | |
|---|---|---|
| Data model | Normalised tables, joins | Denormalised documents or keys, little or no joining |
| Schema | Enforced by the database | Flexible, enforced (or not) by the application |
| Transactions | Strong, multi-row and multi-table | Varies: per document, or limited multi-document |
| Querying | Powerful ad-hoc SQL | Optimised for known access patterns |
| Scaling | Vertical first, read replicas, sharding with effort | Many designed for horizontal scaling from the start |
| Consistency | Strong by default | Often configurable, sometimes eventual |
Myths worth correcting
- “NoSQL is faster.” For the queries it’s designed for, a key-value lookup in Redis is extremely fast. A well-indexed PostgreSQL query is also fast. Performance depends on data modelling and indexing more than on the category. See database indexing.
- “SQL doesn’t scale.” PostgreSQL and MySQL run some of the largest sites in the world, with replicas, caching and sharding. Most applications never outgrow a single well-tuned server. See database replication.
- “Schemaless means no schema.” Your application still has a schema, it’s just not enforced by the database. Inconsistent documents become the app’s problem.
- “You must pick one.” Most real systems use several: PostgreSQL for core data, Redis for cache and queues, a search engine for full text.
Modern relational databases blur the line
PostgreSQL’s JSONB columns store and index JSON documents with SQL querying, and MySQL has a JSON type. You can keep relational integrity for core entities, and flexible JSON for variable attributes, in one database. Extensions add time-series (TimescaleDB) and vector search (pgvector).
How to choose
Choose a relational database (PostgreSQL / MySQL) when:
- the data has clear relationships: users, orders, products, invoices;
- you need transactions across multiple records (payments, inventory);
- you’ll run varied queries and reports you can’t fully predict;
- you’re not sure. It’s the safest default for most applications.
Choose a document store (MongoDB) when:
- records are self-contained documents with varying structure (content management, catalogues with very different attributes, event payloads);
- you mostly read and write whole documents by ID or simple filters;
- the team is comfortable modelling for its access patterns.
Add specialised stores for specific jobs:
- Redis for cache, sessions, rate limits and queues. See Redis vs Memcached;
- Elasticsearch, OpenSearch or Meilisearch for search. See Meilisearch;
- InfluxDB or TimescaleDB for metrics;
- Neo4j for graph traversal;
- a vector database for AI similarity search.
Hosting considerations on a VPS
- Relational databases and MongoDB both benefit most from RAM (cache) and fast SSD storage. See how much RAM a VPS needs.
- Distributed NoSQL systems (Cassandra, MongoDB sharded clusters, Elasticsearch clusters) need several nodes to show their strengths, and need more operational work.
- Whatever you choose: bind to private networks, enable authentication, and automate backups. See database backup automation.
Quick reference
| Need | Good fit |
|---|---|
| General web app data | PostgreSQL or MySQL |
| Flexible documents | MongoDB (or PostgreSQL JSONB) |
| Cache, sessions | Redis / Valkey |
| Full-text search | Elasticsearch, OpenSearch, Meilisearch |
| Relationships and paths | Neo4j |
| Metrics | TimescaleDB, InfluxDB |
| Embeddings | pgvector, Qdrant |
Related: MongoDB vs MySQL and MySQL vs PostgreSQL.