When a team picks the database for a new application —or evaluates modernizing an existing one— the comparison almost always comes down to the two most widely used open-source relational databases in the world: PostgreSQL and MySQL. Both are mature, free at their core, run on any cloud, and have enormous communities. The difference is not which one is “more powerful,” but which problem each one solves best — and choosing without criteria is paid for later in data integrity, in cost, or in a migration that turns uphill.
This guide compares both options with decision criteria for technology leaders, not just for database administrators.
What each one is, in a sentence
- PostgreSQL is an object-relational database driven by an open community, known for its adherence to the SQL standard, its data integrity, its advanced types and its extensibility. It ships under a permissive license, with no single owning company.
- MySQL is the most widespread open-source relational database in web applications, now owned by Oracle and available under dual licensing (an open-source edition under GPL and commercial editions). Its default storage engine, InnoDB, provides transactions and row-level locking.
Both cover the basics —tables, SQL, transactions, replicas— and in modern versions they resemble each other more than before. But underneath they carry different philosophies, and that difference is what decides.
The criteria that actually decide
1. Data and query complexity
This criterion tips the scale the most. PostgreSQL was designed for rich data models: it supports advanced types such as JSONB (binary, indexable JSON), arrays, ranges and custom types, plus extensions like PostGIS for geospatial data. Its engine uses multiversion concurrency control (MVCC), which holds up well under simultaneous reads and writes and complex analytical queries.
MySQL 8.0 closed much of the historical gap: it now supports common table expressions (CTEs, both recursive and non-recursive) and window functions, which used to be PostgreSQL-only territory. Even so, for elaborate data models, analytical reporting over the same database, or strict integrity requirements, PostgreSQL still has the edge.
2. Data integrity and standard compliance
PostgreSQL is known for its strict adherence to the SQL standard and for very predictable transactional behavior, which reduces surprises in workloads where a wrong value has a real cost —finance, healthcare, inventory. MySQL is more permissive by design and prioritizes speed and simplicity; with InnoDB it is ACID-compliant, but it is worth reviewing configurations and strict modes for each case.
3. Speed and workload pattern
MySQL has a well-earned reputation for being fast and lightweight in read-heavy web applications with simple queries, and it carries a giant ecosystem of frameworks, hosting and talent. For a content site, a standard e-commerce store or a CRUD backend, it is a safe and productive choice.
PostgreSQL performs very well under mixed read/write concurrency and heavy queries, thanks to its MVCC. If your application blends transactions and analytics, or if you expect queries to grow complex over time, that behavior is an advantage.
4. Artificial intelligence and vector search
Here PostgreSQL opened a concrete lead. The pgvector extension lets you store embeddings and run similarity searches inside the database itself, and it is supported on both Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL. This enables semantic search and retrieval-augmented generation (RAG) patterns over your own data, integrated with models in Amazon Bedrock, without adding a separate vector database. For products that embed AI, it is a strong argument in favor of PostgreSQL.
5. Licensing and governance
PostgreSQL ships under the PostgreSQL License, permissive in style, sustained by a global community with no single owner. MySQL belongs to Oracle and combines an open-source edition (GPL) with commercial editions. For most managed cloud workloads the practical difference is minor, but it defines who sets the roadmap and under what terms — and that weighs in a long-term decision.
PostgreSQL vs MySQL: the decision table
| Criterion | MySQL | PostgreSQL |
|---|---|---|
| Profile | Read-heavy web, simplicity | Complex data, integrity, extensibility |
| Advanced data types | JSON, solid base | JSONB, arrays, geospatial, custom types |
| Complex queries | CTEs and window functions (8.0) | Historical strength, very complete |
| Concurrency | InnoDB, row-level locking | MVCC, simultaneous reads/writes |
| AI / vector search | Via external services | Native pgvector (RDS and Aurora) |
| Licensing | Oracle, GPL + commercial | PostgreSQL License, permissive |
| On AWS | Amazon RDS and Amazon Aurora | Amazon RDS and Amazon Aurora |
What if the answer is not relational? SQL vs NoSQL
Before deciding between PostgreSQL and MySQL, one prior question helps: is your workload really relational? SQL databases shine when data has structure, relationships and needs transactional consistency. When the pattern is key-value at scale, flexible documents, or millisecond latencies at huge volumes, a NoSQL database like Amazon DynamoDB usually fits better.
It is not an either/or choice: many modern architectures combine a relational database for the transactional core with a NoSQL one for catalogs, sessions or events. The right decision starts from the data access pattern, not from the trend.
PostgreSQL vs MySQL on AWS: where you run them
Choosing the engine and choosing where to run it are two separate decisions. Both PostgreSQL and MySQL are managed options on Amazon RDS, which handles patching, backups and high availability. And both are also compatible with Amazon Aurora, the AWS engine that keeps their protocol and syntax on a distributed, higher-performance storage architecture.
In other words: first you decide the engine on application grounds (what we saw above) and then you decide the destination —RDS or Aurora— based on availability, performance and cost. We develop that second decision in detail in Aurora vs RDS: which one fits.
When each one fits
Choose MySQL when you are building a read-heavy web application with simple queries, when you value operational simplicity and a huge ecosystem of talent and tools, or when your stack already revolves around it and works.
Choose PostgreSQL when data integrity and standard compliance are critical, when you work with complex data models or advanced types (JSONB, geospatial), when you anticipate analytical queries over the same database, or when your product embeds AI and you want native vector search with pgvector.
And remember it is not a one-time decision: the engine can change with a planned migration, and on AWS there are conversion and replication tools that reduce the cutover risk.
How we approach it at Caleidos
At Caleidos, as an AWS Advanced Tier Services Partner, this decision is part of our data and analytics and modernization practice: we start from the real data access pattern and where the product is heading, not from an engine preference. When AI is in play, we evaluate PostgreSQL with pgvector as a unified base; when the requirement is web speed and simplicity, MySQL delivers without overdesigning. If you want to understand the technology base first, we go deeper on Amazon RDS.
Evaluating which database to use on AWS?
Let’s talk about your case: in 30 minutes we give you a concrete read on whether your application fits better in PostgreSQL, in MySQL, or in an architecture that combines relational and NoSQL.
