Your choice of database is one of the hardest decisions to undo. Change your frontend framework and you rewrite components. Change your API design and you update routes. Change your database and you migrate data, rewrite queries, rearchitect application logic, and often discover data integrity issues you did not know you had. This decision deserves more careful thought than it usually gets.
The standard advice — "use whatever you know" — is reasonable for prototypes. For production systems that will run for years, it is insufficient. MySQL, PostgreSQL, and MongoDB each have genuine strengths and real weaknesses. The right database for a social media platform is not the right database for a financial ledger. The right database for a three-person startup is not necessarily right for a team of thirty.
This comparison focuses on 2026 realities. PostgreSQL has narrowed MongoDB's document storage advantages substantially with its JSONB improvements and the pgvector extension for AI workloads. MongoDB has added transactions and schema validation that eliminate some of its historical weaknesses. MySQL 8.0 brought significant improvements over MySQL 5.7, which many production systems still run. Understanding the current state of each matters more than repeating conventional wisdom from 2018.
According to the DB-Engines Ranking (March 2026), the popularity order among relational databases places Oracle first, MySQL second, and PostgreSQL third — but among new projects and startups making fresh technology choices, PostgreSQL has overtaken MySQL in Stack Overflow's Developer Survey for the third consecutive year. MongoDB holds the top spot among document databases with no close second.
"Show me your data model and I will tell you your future." — Martin Kleppmann, author of 'Designing Data-Intensive Applications'
Key Differences at a Glance
| Feature | MySQL 8.0 | PostgreSQL 16 | MongoDB 7 |
|---|---|---|---|
| License | GPL / Commercial | PostgreSQL (permissive) | SSPL (restrictive for hosting) |
| Data model | Relational | Relational + JSONB | Document (BSON) |
| ACID transactions | Yes (InnoDB) | Yes | Yes (since 4.0) |
| JSON support | Basic | JSONB (excellent) | Native (excellent) |
| Full-text search | Basic | Good | Good |
| Horizontal sharding | Vitess (external) | Citus (extension) | Built-in |
| Read replicas | Yes | Yes | Yes (replica sets) |
| Stored procedures | Yes | Yes | Limited |
| Partitioning | Yes | Excellent | Yes |
| Schema enforcement | Required | Required | Optional (validator) |
| Managed cloud options | Many (RDS, PlanetScale, etc.) | Many (RDS, Supabase, Neon) | Atlas (primary) |
| Default port | 3306 | 5432 | 27017 |
| Vector search (AI) | No | Yes (pgvector extension) | Yes (Atlas Vector Search) |
| Geographic queries | Limited | Excellent (PostGIS) | Good (2dsphere index) |
| Window functions | Yes (8.0+) | Yes (full, since 8.4) | No (aggregation pipeline) |
| CTE support | Yes (8.0+) | Yes (full, recursive) | No |
| Connection model | Thread-per-connection | Process-per-connection | Thread pool |
| DB-Engines rank (March 2026) | #2 | #3 | #5 |
MySQL: The Workhorse That Built the Web
MySQL powered the internet's first era of scale. Facebook, Twitter, Airbnb, and YouTube all built on MySQL at various points. Its success came from predictability, documentation, and ubiquity — virtually every web host supported it, virtually every web developer knew SQL, and the ecosystem of tools, ORMs, and backup solutions was unmatched.
To understand MySQL's staying power, consider the scale of its deployment: MySQL AB (now Oracle) reported over 10 million active MySQL installations as of their last public disclosure. WordPress's requirement for MySQL or MariaDB alone accounts for hundreds of millions of installations. The ecosystem around MySQL — including MariaDB, Percona Server, and PlanetScale's Vitess — means that MySQL-compatible databases will be maintained long after any individual corporation's involvement.
MySQL's Genuine Strengths
MySQL's read performance for simple queries is hard to beat. In workloads dominated by SELECT statements on well-indexed tables — the pattern of most web applications — MySQL performs extremely well. The InnoDB buffer pool, combined with MySQL's query optimizer, is well-tuned for this pattern. Benchmark studies from Percona show MySQL 8.0 handling simple primary key lookups at over 500,000 queries per second on commodity hardware with appropriate tuning.
InnoDB, MySQL's default storage engine since version 5.5, provides full ACID compliance, row-level locking, and foreign key support. The reliability story is strong. For applications where data integrity is critical — financial transactions, inventory management, user authentication — InnoDB's guarantees are well-proven across millions of production deployments.
The LAMP stack integration (Linux, Apache, MySQL, PHP) remains relevant in 2026. Huge amounts of web infrastructure run on this combination. WordPress, Drupal, and many legacy PHP applications assume MySQL. If you are working in or near this ecosystem, MySQL is the path of least resistance — and the operational knowledge in your team is likely to already include MySQL administration.
PlanetScale, the MySQL-compatible database built on Vitess, has made MySQL sharding accessible to teams without dedicated database expertise. PlanetScale's branching model (treating database schema changes like Git branches) and non-blocking schema migrations address two of MySQL's historic operational pain points. If MySQL is the right database but operational complexity is a concern, PlanetScale is worth evaluating.
MySQL's Honest Weaknesses
MySQL's SQL compliance is imperfect. It accepts some queries that other databases would reject, producing unexpected results rather than errors. Before MySQL 8.0, certain GROUP BY behaviors violated the SQL standard and produced results that were technically wrong but silently accepted. Window functions, common table expressions, and recursive queries arrived in MySQL 8.0 after being standard in PostgreSQL for years. Developers accustomed to PostgreSQL's stricter SQL behavior regularly encounter MySQL quirks.
The JSON support added in MySQL 5.7 is functional but less capable than PostgreSQL's JSONB. JSON columns in MySQL cannot be indexed with the same flexibility as JSONB GIN indexes, and the JSON query operators are less expressive. Specifically, MySQL lacks the ability to index arbitrary paths within a JSON document without explicitly creating a generated column — PostgreSQL can index an entire JSON document's contents with a single GIN index declaration.
The licensing situation requires attention for commercial use. MySQL is owned by Oracle, and while the Community Edition is GPL, many enterprise features require commercial licenses. The GPL license also creates complications for companies that distribute MySQL as part of a product. PostgreSQL's permissive BSD-style license avoids these concerns entirely. MariaDB, the GPL-compatible MySQL fork created after Oracle's acquisition, provides a licensing alternative that some companies prefer.
PostgreSQL: The Engineer's Database
PostgreSQL is what you get when a database is designed by people who care deeply about correctness, standards compliance, and extensibility. It is the database that specialists tend to choose when they have a free hand, and its market share has grown steadily as teams have prioritized developer experience over LAMP-stack familiarity.
According to Stack Overflow's 2025 Developer Survey, PostgreSQL was the most used database among professional developers for the third year running, with 49.7% of respondents reporting its use. MySQL came second at 40.3%. The gap has widened each year since 2022, reflecting a generational shift in how developers are trained and what defaults cloud providers recommend.
"PostgreSQL is not just a database. It is a platform for building databases. The extension system means you can add capabilities that other vendors would need to build entirely separate products for." — Bruce Momjian, PostgreSQL Core Team member, speaking at PGConf 2024
What Makes PostgreSQL Different
The feature set is genuinely broader than MySQL. Partial indexes let you index a subset of rows, dramatically reducing index size for tables with many null values or where you only query a specific status. Expression indexes let you index the result of a function, enabling fast queries on computed values. GIN indexes for JSONB columns let you index the entire contents of a JSON document efficiently.
PostgreSQL's window functions, CTEs, lateral joins, and full-text search capabilities are more powerful and more standard-compliant than MySQL's equivalents. Writing complex analytical queries is materially easier. The EXPLAIN ANALYZE output is more detailed and easier to interpret — it shows buffer hit rates, loop counts, and timing for every node in the query plan, which is invaluable when debugging slow queries.
The extension ecosystem is a superpower. PostGIS adds full geographic information system capabilities — real spatial indexing, distance calculations, geographic projections, and topology operations that would otherwise require a dedicated GIS server. TimescaleDB transforms PostgreSQL into a time-series database with automatic partitioning by time and compression ratios of up to 90% for time-series data. pgvector, increasingly relevant in 2026's AI application landscape, adds vector similarity search that enables semantic search and embedding storage directly in PostgreSQL. Citus shards PostgreSQL horizontally across multiple nodes, turning a single-node database into a distributed system.
JSONB: PostgreSQL's Answer to MongoDB
JSONB (binary JSON) stores JSON data in a decomposed binary format that enables indexing and efficient querying. A JSONB column can hold arbitrary nested JSON, and GIN indexes on that column support queries like "find all rows where the JSON document contains key 'active' with value true" without scanning the entire table.
The practical implication is that many use cases that might drive teams toward MongoDB can be satisfied within PostgreSQL. You get the flexibility of document storage for metadata, user preferences, or configuration alongside the reliability of relational tables for core business data. Running one database instead of two reduces operational complexity, reduces infrastructure cost, and eliminates the consistency challenges that come from synchronizing data across two data stores.
A concrete example: a SaaS application might store users in a normalized relational table (fixed schema, foreign keys, constraints) while storing user_settings as JSONB (variable structure per user, no schema migration needed when adding new settings). This hybrid approach — relational for structure, JSONB for flexibility — is impossible in MongoDB and awkward in MySQL.
pgvector and AI Applications
In 2026, the explosion of AI applications that use vector embeddings has made pgvector one of the most significant reasons to choose PostgreSQL for new projects. Vector embeddings — numerical representations of text, images, or other data produced by machine learning models — are the foundation of semantic search, recommendation systems, and retrieval-augmented generation (RAG) systems.
pgvector, released in 2021 and now at version 0.7, adds a vector data type to PostgreSQL and supports approximate nearest-neighbor search using HNSW and IVFFlat indexing algorithms. A query like "find the 10 articles most semantically similar to this user query" can run in milliseconds on a properly indexed table with millions of vectors.
The alternative — maintaining a separate vector database like Pinecone, Weaviate, or Qdrant alongside your relational database — adds infrastructure cost, operational complexity, and the consistency problems that come from keeping two systems synchronized. For most applications, pgvector within PostgreSQL is sufficient and substantially simpler.
PostgreSQL's Limitations
PostgreSQL's write performance under very high concurrency has historically lagged MySQL in specific benchmarks, though the gap has narrowed in recent versions. The process-per-connection model means each connection spawns a separate operating system process. For applications with thousands of concurrent connections, PgBouncer connection pooling is essentially mandatory rather than optional — it collapses thousands of application connections into a smaller pool of actual database connections.
The operational learning curve is steeper than MySQL. Vacuum, autovacuum, table bloat, and index bloat are concepts that MySQL developers encounter much less frequently. PostgreSQL uses a multi-version concurrency control (MVCC) system where deleted and updated rows are not immediately removed from disk — a background vacuum process cleans them up. Without understanding this mechanism, PostgreSQL performance can degrade in ways that surprise teams coming from a MySQL background.
MongoDB: Documents First
MongoDB launched in 2009 with a promise: what if you could store data the way application code thinks about it — as nested objects with variable structure — rather than forcing it into flat relational tables? That promise resonated with a generation of developers who found SQL foreign key relationships and normalization tedious.
MongoDB has matured substantially since its early "web scale" marketing era. The platform now has multi-document ACID transactions, schema validation, time-series collections, and Atlas Vector Search. Gartner placed MongoDB as a Leader in the 2024 Cloud Database Management Systems Magic Quadrant, reflecting its enterprise legitimacy.
The Document Model's Real Advantages
For genuinely document-centric data, the document model is more natural. A blog post with a variable number of tags, an e-commerce product with category-specific attributes, a user profile with optional sections — these fit MongoDB's model without the complexity of junction tables or nullable columns.
The MongoDB query language, while not SQL, is expressive for document operations. The aggregation pipeline lets you filter, project, group, unwind arrays, and compute values in a composable way. For teams that primarily think in JavaScript and JSON, the transition is smooth. The $lookup stage in the aggregation pipeline performs left outer joins between collections, though performance degrades at scale compared to PostgreSQL's join optimization.
MongoDB's horizontal scaling story is more built-in than either MySQL or PostgreSQL. Sharding — distributing data across multiple servers based on a shard key — is a first-class feature with operational tooling. For write-heavy workloads at very high scale, this architecture is easier to operate than sharding a PostgreSQL cluster via Citus. The MongoDB documentation provides clear guidance on shard key selection, chunk migration, and balancer configuration that reflects years of production learning.
MongoDB's Historical Problems (Mostly Solved)
MongoDB's early reputation for data loss came from default write concern settings that prioritized performance over durability. By default in early versions, writes were acknowledged before being flushed to disk. These defaults changed in MongoDB 3.0, and current defaults are safe. The reputation lingered longer than the problem did — a useful reminder to evaluate tools on their current state rather than their 2013 state.
The lack of multi-document transactions was a genuine architectural limitation for applications with referential integrity requirements. MongoDB 4.0 added ACID transactions across multiple documents and collections. They work, though they carry a performance overhead compared to single-document operations. The MongoDB documentation recommends designing schemas to avoid multi-document transactions where possible — embedding related data in a single document rather than referencing across collections. This design guidance is correct but differs from relational thinking.
The SSPL license introduced in MongoDB 3.6 is more restrictive than MIT or Apache licenses. The Server Side Public License requires companies that offer MongoDB as a managed service to open-source their entire stack — not just modifications to MongoDB itself. This does not affect typical application development, but it caused AWS, Google, and Azure to discontinue their MongoDB-compatible managed services and create their own document database products (DocumentDB, Firestore, Cosmos DB for MongoDB API). If you want a fully MongoDB-compatible managed service, MongoDB Atlas is essentially your only option.
Atlas: The Managed MongoDB Experience
MongoDB Atlas, the managed cloud service, has become the primary way most teams run MongoDB in production. It handles sharding, backups, monitoring, scaling, and version upgrades. Atlas includes a vector search capability for AI applications, full-text search via Lucene integration, and a Charts feature for data visualization.
Atlas pricing is higher than RDS equivalents at comparable specifications. An M10 dedicated cluster (2 vCPUs, 2GB RAM) starts at approximately $57/month. A comparable RDS PostgreSQL instance costs approximately $30-40/month. However, Atlas includes operational features (automatic backups, point-in-time recovery, automated failover) that you would need to configure manually on self-managed instances. For teams without dedicated database operations expertise, the premium over self-managed instances is frequently worth paying.
Performance in Practice
Benchmark results vary dramatically by workload, and published benchmarks are often produced by the database vendor. These generalizations hold up across independent testing from Percona, EnterpriseDB, and Fauna's open benchmark suite:
Simple read queries on indexed columns: MySQL is marginally fastest, PostgreSQL is comparable (within 5-10%), MongoDB is slightly slower for equivalent point queries due to BSON deserialization overhead.
Complex analytical queries with aggregations: PostgreSQL is the clear winner. Its query planner handles complex joins and aggregations better than MySQL's, and MongoDB's aggregation pipeline, while powerful, cannot match the flexibility of full SQL. On TPC-H benchmark queries (a standard analytical workload), PostgreSQL typically outperforms MySQL by 20-40% on complex multi-join queries.
High-volume document inserts: MongoDB is fastest for bulk document writes when using unordered inserts, appropriate write concerns, and a well-chosen shard key. For append-heavy workloads like event logging, MongoDB's document model and write path are genuinely faster.
Mixed read/write workloads: All three are comparable in typical web application workloads. The 80/20 read/write pattern of most CRUD applications does not produce meaningful differences between the three databases when properly indexed. The bottleneck is almost always the query planner encountering a missing index or a schema design choice, not the database engine itself.
JSON document queries: PostgreSQL JSONB with GIN indexes is comparable to MongoDB for most query patterns. MongoDB is faster for deeply nested document traversals and for queries that rely on MongoDB-specific operators like $elemMatch on embedded arrays.
Vector similarity search: PostgreSQL with pgvector and HNSW indexing is fast enough for production applications up to approximately 10-50 million vectors on a single node. MongoDB Atlas Vector Search scales horizontally and handles larger datasets more easily. Both are significantly faster than brute-force cosine similarity computation.
Pricing and Managed Cloud Options
All three databases are free to self-host on your own infrastructure. Managed service pricing is where meaningful differences appear:
MySQL: Amazon RDS MySQL starts at approximately $25/month for a db.t3.micro instance (1 vCPU, 1GB RAM). Aurora MySQL, Amazon's MySQL-compatible managed database, starts higher at approximately $65/month for the smallest dedicated instance but offers better performance, multi-AZ reliability, and faster failover. PlanetScale offers a free tier with 5GB storage and 1 billion row reads per month — one of the most generous free tiers in the managed database space.
PostgreSQL: Amazon RDS PostgreSQL is priced similarly to RDS MySQL. Supabase offers a generous free tier: 500MB database storage, 2GB file storage, and full PostgreSQL access with no row-limit restrictions. Neon provides serverless PostgreSQL with a consumption-based pricing model and autoscaling to zero when idle, making it cost-effective for development environments and low-traffic production sites. Railway and Render also offer simple PostgreSQL hosting starting at $5-7/month.
MongoDB: Atlas starts at $0 for a 512MB M0 shared cluster — sufficient for development and very small production workloads. The M10 dedicated cluster starts at approximately $57/month. At the M30 tier (4 vCPUs, 16GB RAM), Atlas costs approximately $400/month, compared to approximately $200/month for a comparable RDS PostgreSQL instance. The Atlas premium is real but includes the operational features described above.
Recommendations by Use Case
Traditional web application (user accounts, sessions, relational data): PostgreSQL. Better feature set than MySQL, no practical performance disadvantage for typical workloads, better licensing, and JSONB covers any document storage needs without adding a second database.
WordPress or LAMP stack application: MySQL. The ecosystem assumptions are deep and fighting them is not worth it. WordPress's database schema is built for MySQL, the available optimization tools (WP-CLI, Percona Toolkit) assume MySQL, and the operational knowledge in the WordPress community is MySQL-focused.
Application requiring flexible schema for user-generated content: PostgreSQL with JSONB for most cases. MongoDB when the entire data model is genuinely document-centric, the team's JavaScript expertise is stronger than their SQL expertise, and horizontal sharding is a day-one requirement.
High write volume, horizontal scale from day one: MongoDB with Atlas. The built-in sharding is operationally easier than PostgreSQL sharding solutions (Citus requires more manual configuration). If you genuinely need to write millions of documents per second across multiple geographic regions, MongoDB's architecture is better suited.
Analytics or reporting alongside transactional data: PostgreSQL. Window functions, complex joins, materialized views, and extensions like TimescaleDB for time-series data handle this better than the alternatives. If you need OLAP-scale analytics, consider PostgreSQL for OLTP with a separate columnar store (Redshift, BigQuery, DuckDB) for analytics.
AI applications storing embeddings or doing semantic search: PostgreSQL with pgvector. In 2026, this has become a compelling reason to choose PostgreSQL specifically. Most new AI applications use PostgreSQL as their primary database with pgvector, avoiding the operational complexity of a separate vector store.
Regulated industries (financial services, healthcare, government): PostgreSQL or MySQL. MongoDB's SSPL licensing and the relative immaturity of its audit logging compared to enterprise relational databases create friction in compliance-heavy procurement processes. PostgreSQL's audit extension (pgaudit) and mature role-based access control are well-understood by security auditors.
Migration Considerations
Moving between these databases is expensive. The cost is worth understanding before you commit.
Migrating from MySQL to PostgreSQL is the most common migration in this category. MySQL and PostgreSQL are both relational databases with similar SQL dialects, but the differences — MySQL's case-insensitive string comparison, its different handling of GROUP BY, its JSON type differences — mean a migration is never a simple export/import. Tools like pgloader automate much of the process but require testing each query against PostgreSQL's stricter behavior.
Migrating from MongoDB to PostgreSQL requires rethinking your data model. A document with embedded arrays and nested objects does not map cleanly to normalized relational tables. Teams frequently discover during migration that their MongoDB schema reflected application-layer convenience rather than the actual relationships in the data. This is not necessarily bad — the migration is an opportunity to build a more correct model — but it is time-consuming.
Migrating from PostgreSQL or MySQL to MongoDB is less common in the direction of "we need more flexibility" and more common in the direction of "we need horizontal sharding and document storage for this specific new service." Teams often run both rather than migrating fully.
References
- PostgreSQL 16 Release Notes — postgresql.org
- MySQL 8.0 Reference Manual — dev.mysql.com
- MongoDB 7 Documentation — mongodb.com/docs
- 'Designing Data-Intensive Applications' — Martin Kleppmann, O'Reilly 2017
- 'Use the Index, Luke' — SQL Performance Explained — use-the-index-luke.com
- pgvector GitHub Repository — github.com/pgvector/pgvector
- MongoDB SSPL License Analysis — opensource.org
- TimescaleDB Documentation — timescale.com/docs
- Citus Documentation — citusdata.com/docs
- Stack Overflow Developer Survey 2025 — survey.stackoverflow.co/2025
- DB-Engines Ranking March 2026 — db-engines.com/en/ranking
- Percona MySQL 8.0 Benchmark Report 2024 — percona.com/resources
- MongoDB Atlas pricing — mongodb.com/pricing/cloud
- Supabase pricing and free tier — supabase.com/pricing
- Neon serverless PostgreSQL — neon.tech
- PlanetScale free tier — planetscale.com/pricing
- Gartner Magic Quadrant for Cloud DBMS 2024 — gartner.com
- pgaudit documentation — github.com/pgaudit/pgaudit
Frequently Asked Questions
Is PostgreSQL better than MySQL for most applications?
For greenfield projects in 2026, PostgreSQL is generally the better choice between the two. PostgreSQL has native JSON and JSONB support that rivals MongoDB for document-style queries, better compliance with SQL standards, more advanced indexing options including partial and expression indexes, and a more permissive open-source license. MySQL's main advantages are its ubiquity in shared hosting environments, its integration with the LAMP stack, and marginal read performance advantages in specific high-read scenarios. If your hosting environment mandates MySQL — many budget shared hosts only offer MySQL — there is no practical reason to fight that constraint. But for a new application where you choose freely, PostgreSQL's feature set is objectively broader. The performance differences in typical web application workloads are negligible.
When should you use MongoDB instead of a relational database?
MongoDB is genuinely well-suited for applications where the data schema is legitimately unknown or evolving rapidly, where you need to store documents with highly variable structures, or where the development team's primary expertise is JavaScript and the document model feels more natural. Real-world examples where MongoDB often wins: content management systems with custom field structures, user-generated content with unpredictable metadata, product catalogs with varying attribute sets per product category, and real-time logging or analytics where you are writing far more than reading. The cases where MongoDB is often chosen incorrectly are applications that have relational data — users, orders, products — where joins would be natural but the team chose MongoDB to avoid 'thinking about schemas.' Forcing relational data into documents introduces complexity without benefit.
How does PostgreSQL's JSON support compare to MongoDB?
PostgreSQL's JSONB type stores JSON as a binary format that supports indexing, efficient querying with GIN indexes, and a rich set of operators for filtering and extracting nested values. For applications that need document-style storage alongside relational tables, PostgreSQL JSONB is a legitimate alternative to MongoDB. MongoDB's query language is still more expressive for deeply nested document operations, and its aggregation pipeline is designed specifically for document data. But for a typical web application that stores 'extra metadata' as JSON alongside structured relational data, PostgreSQL's JSONB eliminates the need to run a separate MongoDB instance. The hybrid approach — relational tables for core entities, JSONB columns for flexible metadata — is now common in production PostgreSQL deployments.
Which database scales best for high-traffic applications?
The scaling question depends on whether you need to scale reads, writes, or both. PostgreSQL scales reads well through read replicas and connection pooling via PgBouncer. Write scaling requires sharding, which PostgreSQL supports via Citus or manual partitioning. MongoDB's built-in horizontal scaling through sharding is more operationally straightforward for write-heavy workloads, which is why it historically appealed to large-scale applications. MySQL with InnoDB scales reads very well and has mature replication tooling. In practice, most web applications never hit the scale where these architectural differences matter — vertical scaling and read replicas handle the vast majority of production workloads. Choose your database for developer productivity first, scaling architecture second.
Is MongoDB's 'schemaless' design an advantage or a problem?
Both, depending on context and team discipline. The schemaless design is a genuine advantage during early-stage development when requirements change frequently — you can add fields to documents without migrations, adjust data structures on the fly, and iterate quickly. The problem emerges as applications mature. Without enforced schemas, data inconsistency accumulates: some documents have a field, others do not, some have the field as a string, others as an integer. Queries become defensive, application code fills with null checks, and understanding the actual shape of your data requires reading source code rather than a schema definition. MongoDB added schema validation in version 3.6, and using it is strongly recommended for production applications. With validation enforced, much of the 'schemaless' advantage disappears — but you retain the document storage model.
