MongoDB vs MySQL

Quick verdict

MongoDB is a document database. Records are BSON documents (a binary form of JSON) stored in collections, documents in one collection do not need the same fields, and you query them with the MongoDB Query API (find(), update operators and aggregation pipelines) rather than SQL. MongoDB Community Server is source-available under the Server Side Public License (SSPL) v1.0; MongoDB, Inc. also sells MongoDB Enterprise Advanced and runs the MongoDB Atlas cloud service. The current release documented in the MongoDB manual is 9.0.

MySQL is a relational database owned by Oracle. Data lives in tables with declared column types, managed by the transactional InnoDB storage engine and queried with SQL. Two features matter for this comparison: a native JSON column type, and the MySQL Document Store, which lets applications use MySQL as a schema-less collection of JSON documents through the X DevAPI. MySQL Community Server is free under GPLv2, with commercial editions and the MySQL HeatWave cloud service from Oracle. MySQL uses calendar versioning: 26.7.0 is the current Innovation release, and 8.4 and 9.7 are the Long-Term Support lines.

If you are deciding between relational and document databases in general, start with SQL vs NoSQL. If PostgreSQL is also on your list, MongoDB vs PostgreSQL covers its jsonb type and the PostgreSQL side of the decision; this page stays with MySQL.

Side by side

Key differences

JSON in MySQL versus documents in MongoDB

MySQL's JSON type validates documents on insert (invalid JSON produces an error) and stores them in an internal binary format that the Reference Manual says permits quick read access to document elements. The manual is explicit about one limit: JSON columns are not indexed directly. You index a scalar extracted into a generated column, or, for arrays, use an InnoDB multi-valued index. MySQL can also update JSON partially in place with JSON_SET(), JSON_REPLACE() and JSON_REMOVE() when the documented conditions are met.

In MongoDB the document is the unit of storage and indexing: you index a field path such as "customer.country" directly, and an index on an array field becomes a multikey index. The same query, shipped orders for UK customers, written both ways:

// MongoDB (mongosh)
db.orders.createIndex({ status: 1 })
db.orders.find(
  { status: "shipped", "customer.country": "UK" },
  { _id: 0, order_no: 1, total: 1 }
)

-- MySQL 8.4: JSON column, indexed through a generated column
CREATE TABLE orders (
  id     BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  doc    JSON NOT NULL,
  status VARCHAR(20) GENERATED ALWAYS AS (doc->>'$.status') VIRTUAL,
  INDEX idx_status (status)
);

SELECT doc->>'$.order_no' AS order_no,
       doc->>'$.total'    AS total
FROM   orders
WHERE  status = 'shipped'
  AND  doc->>'$.customer.country' = 'UK';

Matching a value inside an array shows the same pattern. MongoDB queries the array field directly; MySQL uses a multi-valued index with MEMBER OF(), JSON_CONTAINS() or JSON_OVERLAPS():

// MongoDB
db.products.createIndex({ tags: 1 })
db.products.find({ tags: "outdoor" })

-- MySQL 8.4: multi-valued index on a JSON array
CREATE TABLE products (
  id   BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  info JSON,
  INDEX idx_tags ( (CAST(info->'$.tags' AS CHAR(30) ARRAY)) )
);

SELECT id FROM products
WHERE  'outdoor' MEMBER OF (info->'$.tags');

And an update to many records:

// MongoDB
db.orders.updateMany({ status: "pending" }, { $set: { status: "cancelled" } })

-- MySQL
UPDATE orders
SET    doc = JSON_SET(doc, '$.status', 'cancelled')
WHERE  status = 'pending';

MySQL Document Store and the X DevAPI

MySQL also offers a document-style API, which many comparisons miss. The Reference Manual (8.4, 9.7 and 26.7 editions) documents the MySQL Document Store as a way to use MySQL as a schema-less store of JSON documents in collections, and states that X Plugin, which lets the server speak X Protocol, is enabled by default as of MySQL 8.4. Documents are represented internally with the MySQL binary JSON type, and each has an _id. Clients use the X DevAPI through MySQL Shell or connectors; the X DevAPI User Guide (generated August 2026) has implementation notes for Connector/J, Connector/Node.js and MySQL Shell. We found no deprecation notice in the current documentation.

// MySQL Shell, JavaScript mode (X DevAPI)
db.createCollection("orders")
db.orders.add({ order_no: "A-1001", status: "shipped",
                customer: { country: "UK" }, total: 120 })
db.orders.find("status = 'shipped' and customer.country = 'UK'")
  .fields(["order_no", "total"])

In our view the Document Store suits teams already running MySQL that want some collection-style access without adding a second database. It is not a drop-in MongoDB replacement: the API, drivers and query syntax differ, and MongoDB's aggregation pipeline, sharding and Atlas ecosystem have no direct equivalent in it.

Transactions and integrity

InnoDB is transactional for every statement. By default each connection runs with autocommit enabled, so every statement commits on its own, and multi-statement transactions use START TRANSACTION and COMMIT or ROLLBACK. Foreign keys, unique and CHECK constraints keep related tables consistent.

-- MySQL
START TRANSACTION;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
COMMIT;

In MongoDB a write to a single document is atomic without a transaction, and MongoDB's guidance is to model related data as embedded documents and arrays where possible. Multi-document ACID transactions are available on replica sets from 4.0 and sharded clusters from 4.2, but the documentation notes they usually cost more than single-document writes and lists restrictions. There are no foreign keys between collections.

High availability: Group Replication and InnoDB Cluster versus replica sets

MySQL's built-in replication is asynchronous by default, with semisynchronous replication available. For automatic failover, MySQL Group Replication forms a group of servers with built-in failure detection and, in the default single-primary mode, automatic primary election; multi-primary mode lets every member accept writes. The manual sets a maximum of 9 members per group. Group Replication does not redirect clients itself, so Oracle recommends InnoDB Cluster: at least three instances running Group Replication, administered through the AdminAPI in MySQL Shell, with MySQL Router detecting a failover and sending clients to the new primary. InnoDB ClusterSet links clusters in different locations for disaster tolerance.

MongoDB builds this into the database: a replica set has one primary and secondaries, and if the primary is unreachable for longer than electionTimeoutMillis (10 seconds by default) an eligible secondary calls an election. Failover is part of the replica set itself rather than an add-on cluster layer.

Horizontal scaling: sharding

MongoDB sharding is a core, documented feature: collections are distributed across shards (each a replica set) by a shard key, with mongos routers and config servers. Ranged and hashed sharding are documented, and collections can be resharded from 5.0. MongoDB also notes that sharding adds infrastructure complexity and that queries without the shard key are sent to every shard.

Group Replication and InnoDB Cluster copy all data to every member; they add availability and read capacity, not write scale-out. MySQL's distributed option is MySQL NDB Cluster, which the manual describes as an in-memory clustered storage engine in a shared-nothing system, with tables stored on data nodes and reached through SQL nodes. It is a different engine (NDB, not InnoDB) with its own architecture and operational model, so treat it as a separate product decision. Otherwise, splitting InnoDB data across servers is left to the application or to external tooling.

Licences and vendor clouds

MongoDB Community Server releases after 16 October 2018 are under the SSPL v1.0, which is source-available but not approved by the Open Source Initiative; MongoDB's drivers are Apache License 2.0. MySQL Community Server is GPLv2, and Oracle sells a commercial licence for embedding MySQL in distributed products without GPL obligations, plus Enterprise, Standard and Classic editions and NDB Cluster CGE.

Each vendor runs its own cloud service. MongoDB Atlas runs on AWS, Azure and Google Cloud. The HeatWave User Guide lists MySQL HeatWave as available on Oracle Cloud Infrastructure and natively on AWS, and on Azure through Oracle Database Service for Azure or the OCI-Azure Interconnect; Oracle describes HeatWave as one service for transactions and lakehouse-scale analytics. Managed MySQL is also offered by other cloud providers, for example Amazon RDS, which widens your choice of host.

Pricing and licensing

Licences. MongoDB Community Server is free under SSPL v1.0 (earlier versions were AGPL v3.0); MongoDB Enterprise Advanced is sold under a commercial licence, priced by contacting sales. MySQL Community Server is free under GPLv2 with additional permissions described by Oracle; commercial editions and OEM licences are sold by Oracle, and no prices are shown on the MySQL product or "How to Buy" pages. We describe licence terms only; take your own legal advice if licence obligations matter for software you distribute or host.

MongoDB Atlas. Listed on the MongoDB pricing page in October 2026, in USD: a Free tier with 512 MB of storage; Flex at 0.011 USD per hour, up to 30 USD per month, with 5 GB of storage; and Dedicated clusters from 0.08 USD per hour (M10, about 56.94 USD per month as estimated by MongoDB). Prices vary by cloud provider and region, and usage is billed hourly with monthly invoices.

MySQL HeatWave and other managed MySQL. We could not read Oracle's HeatWave pricing pages reliably in October 2026, so we do not quote HeatWave prices; check Oracle's price list for your region. Managed MySQL from other providers (for example Amazon RDS for MySQL) is priced by each provider by instance size, storage and region.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want relational integrity plus richer JSON indexing (GIN indexes on jsonb) and a permissive licence: look at PostgreSQL; see MongoDB vs PostgreSQL and MySQL vs PostgreSQL.
• You are on Microsoft infrastructure and want a relational platform with JSON support: see MongoDB vs SQL Server.
• The data belongs to one application on one device, or you need a local test database: SQLite needs no server; see SQLite vs MySQL.
• Large analytical scans and aggregates are better served by a column-oriented engine or data warehouse than by either operational database.

Final recommendation

Frequently asked questions

Sources

• MongoDB Community Edition licensing
• MongoDB manual: SQL to MongoDB mapping chart
• MongoDB manual: Transactions
• MongoDB manual: Replication
• MongoDB manual: Sharding
• MongoDB Atlas pricing
• MySQL Reference Manual: The JSON data type
• MySQL Reference Manual: CREATE INDEX (multi-valued indexes)
• MySQL Reference Manual: Using MySQL as a Document Store
• X DevAPI User Guide
• MySQL Reference Manual: autocommit, COMMIT and ROLLBACK
• MySQL Reference Manual: Group Replication
• MySQL Reference Manual: Group Replication limitations
• MySQL Shell manual: MySQL InnoDB Cluster
• MySQL Reference Manual: NDB Cluster overview
• HeatWave User Guide: Supported cloud platforms
• MySQL products and editions
• MySQL licensing (OEM and commercial)

Checked October 2026.

How we research comparisons: our editorial method.