Choosing a database for your app is one of the few technical decisions that is genuinely hard to change later. MySQL, PostgreSQL and MongoDB are three of the most widely used options, and each can run a serious production system. The right choice depends on the shape of your data, the questions you need to ask of it and the skills of the team that will look after it.
Relational and document databases
The first difference is the model.
MySQL and PostgreSQL are relational databases. Data lives in tables with rows and columns, and tables link to each other through keys. A customer has orders, an order has items, an item belongs to a product. You query this data with SQL, and the database enforces rules such as "every order must belong to a real customer".
MongoDB is a document database. Data is stored as flexible JSON-like documents. A single document can hold a user and their settings, addresses and preferences together. Different documents in the same collection can have different fields, which makes early changes easy.
Neither model is better in general. Relational databases suit data with many connections and strict rules. Document databases suit data that is naturally grouped together and changes shape often.
MySQL, PostgreSQL and MongoDB compared
| Factor | MySQL | PostgreSQL | MongoDB |
|---|---|---|---|
| Model | Relational | Relational | Document |
| Query language | SQL | SQL, with many extensions | MongoDB query language |
| Schema | Fixed, enforced | Fixed, enforced, plus JSON columns | Flexible |
| Transactions across records | Yes | Yes | Supported, best used sparingly |
| Complex reports and joins | Good | Very strong | Possible, usually more work |
| Typical hosting | Widely available, including shared hosting | Widely available on cloud platforms | Self-hosted or managed cloud service |
| Common pairings | PHP, Laravel, WordPress | Django, Rails, Node.js, data-heavy apps | Node.js, real-time and content apps |
When MySQL is a good choice
MySQL has powered web applications for a very long time and is supported almost everywhere.
- Standard business apps and websites. Customer portals, booking systems, ecommerce and content sites.
- PHP and Laravel projects. The tooling and hosting support are excellent.
- Teams that want simple operations. Many developers and hosting providers know it well, and managed versions are available from every major cloud.
MySQL handles read-heavy workloads well and is easy to find help for.
When PostgreSQL is a good choice
PostgreSQL is often described as the most feature-rich open source relational database.
- Complex data and reporting. Strong support for advanced queries, window functions and analytics.
- Mixed data. Its JSONB columns let you store flexible documents alongside normal tables, which covers many cases where people reach for MongoDB.
- Location and search features. Extensions such as PostGIS add mapping and geographic queries, and built-in full-text search covers simpler search needs.
- Strict data integrity. Good support for constraints and custom data types helps protect important records such as finance or inventory.
For a new product with no strong reason to choose otherwise, PostgreSQL is a safe, flexible default.
When MongoDB is a good choice
MongoDB shines when your data does not fit neatly into tables.
- Rapidly changing data structures. Early products where fields are added and removed often.
- Content and catalogues. Products or articles with very different attributes.
- Event and activity data. Large volumes of logs, sensor readings or user activity.
- JavaScript-heavy teams. Documents map closely to objects in Node.js code.
The trade-off is that flexible data needs discipline. Without agreed rules in the application, documents can drift into inconsistent shapes, and reports that join several collections can become slow or awkward.
How to choose a database
Work through this checklist with your team.
- Sketch your main data. If you draw boxes and lines and see lots of connections, start with a relational database.
- List the reports you need. Finance, admin dashboards and exports favour SQL.
- Check how often the structure will change. Constant change in early product discovery can favour MongoDB or PostgreSQL with JSON columns.
- Look at your framework. Laravel works well with MySQL and PostgreSQL. Django has its strongest support for PostgreSQL. Node.js works well with all three.
- Consider who will run it. A managed database service from a cloud provider reduces the work of backups, updates and scaling for any of the three.
- Think about integrity. If mistakes in the data would cost money or trust, choose the option with the strongest rules.
Many products also use more than one database. A relational database might hold accounts and orders, while a separate store handles search, caching or analytics. Start with one and add others only when there is a clear need. If your app is mobile first, our article on Firebase for mobile apps covers another option.
Frequently asked questions
Which database is fastest?
There is no single answer. Each is fast when the data model, indexes and queries suit it. Poor indexing slows down any database far more than the choice of product.
Can we switch databases later?
Moving between MySQL and PostgreSQL is usually manageable with planning. Moving between a relational database and MongoDB is harder because the data model and much of the code must change.
Are these databases free to use?
MySQL and PostgreSQL have free open source editions, and MongoDB has a free community edition. Managed cloud versions and commercial editions are paid, so check current licence terms and pricing for your situation.
Need help designing your data model or choosing a database? Our cloud, DevOps and backend team designs and runs databases for web and mobile products.