A Systematic Comparative Study of MySQL and PostgreSQL

Overview

A systematic comparison of MySQL and PostgreSQL based on official documentation, covering governance, licensing, storage architecture, transaction isolation, SQL compatibility, JSON, indexes, extensions, replication, backup, security, operations, and metadata-system suitability.

Abstract

MySQL and PostgreSQL are both widely used open-source relational database management systems, but they differ in project governance, licensing, data models, transaction isolation, SQL standard compatibility, indexing systems, JSON support, extension mechanisms, replication models, backup and recovery, and operational characteristics. Based on the official MySQL 8.4 LTS documentation, PostgreSQL 18 documentation, MySQL product documentation, and PostgreSQL project materials, this article conducts a systematic comparison between MySQL and PostgreSQL. The findings show that MySQL uses InnoDB as its default transactional storage engine and provides transactions, replication, Group Replication, backup, security, and management capabilities around relational OLTP scenarios. PostgreSQL is positioned as an object-relational database system and provides rich built-in capabilities in SQL extensibility, type systems, index types, JSONB, extension mechanisms, and logical replication. Both systems support ACID, transaction isolation, replication, secure connections, and backup and recovery, but they differ in implementation paths, default isolation levels, extensibility, and ecosystem governance.

Keywords: MySQL; PostgreSQL; relational database; transaction isolation; MVCC; JSON; replication; high availability; database selection

1. Introduction

Relational database management systems are important components for storing structured data, transactional data, and metadata in enterprise applications, internet systems, and infrastructure platforms. MySQL and PostgreSQL are both open-source database systems, but their development paths, architectures, and capability boundaries are not the same.

MySQL Community Edition is the freely downloadable version officially provided by MySQL and uses the GPL license. Starting with MySQL 8.4, the official documentation divides the release model into Long-Term Support and Innovation tracks. Both include bug fixes and security fixes and are officially described as production-grade quality. 1

PostgreSQL officially describes itself as an open-source object-relational database system that uses and extends the SQL language and has a long history of core platform development. PostgreSQL uses the PostgreSQL License, which is officially described as a liberal open-source license similar to BSD or MIT. 3

This article does not make judgments based on third-party performance benchmarks and does not cite unofficial blogs as evidence. It only summarizes key engineering differences based on verifiable function descriptions in official documentation.

2. Research Scope and Method

This article covers the following areas:

1. Project positioning and licensing.
2. Version release model.
3. Storage architecture and transaction model.
4. Transaction isolation and MVCC.
5. SQL standard compatibility.
6. Data types and JSON capabilities.
7. Indexing systems.
8. Extension capabilities.
9. Replication and high availability.
10. Backup and recovery.
11. Security capabilities.
12. Operations and maintenance characteristics.
13. Suitability for metadata-oriented systems such as configuration centers.

The sources mainly come from the MySQL Reference Manual, PostgreSQL Documentation, MySQL official product pages, PostgreSQL official project pages, and the official PostgreSQL license description. Since MySQL and PostgreSQL continue to evolve, version-related descriptions in this article mainly use MySQL 8.4 LTS and PostgreSQL 18 official documentation as their basis.

3. Project Positioning and Licensing

3.1 MySQL

MySQL is an open-source relational database management system. MySQL Community Edition is freely downloadable and uses the GPL license. 1 MySQL also provides enterprise editions, cloud services, and related toolchains. The official MySQL 8.4 documentation divides MySQL releases into Long-Term Support and Innovation releases. 2

MySQL's architecture supports multiple storage engines. InnoDB is the current default storage engine for MySQL. The official MySQL documentation states that when no other storage engine is explicitly specified, tables are created with InnoDB by default. 5

3.2 PostgreSQL

PostgreSQL is officially defined as an open-source object-relational database system that uses and extends SQL. 3 PostgreSQL uses the PostgreSQL License, which is officially described as a liberal open-source license similar to BSD or MIT. 4

PostgreSQL is not a multi-storage-engine system. Instead, it provides tables, transactions, MVCC, indexes, extensions, replication, WAL, and other capabilities through a unified database kernel. PostgreSQL official documentation also emphasizes extensibility: extensions can add functions, data types, operators, index support methods, and other objects to the database. [6]

3.3 Summary

Dimension	MySQL	PostgreSQL
Official positioning	Open-source relational database management system	Open-source object-relational database system
Community license	GPL	PostgreSQL License
Release model	LTS and Innovation tracks	Continuous major-version releases and maintenance
Storage architecture	Multiple storage engines, InnoDB as the default transactional engine	Unified database kernel
Extension model	Plugins, components, storage engines, and other mechanisms	CREATE EXTENSION and extension ecosystem

4. Storage Architecture and Transaction Model

4.1 MySQL InnoDB

MySQL supports multiple storage engines, but modern MySQL's default transactional storage engine is InnoDB. InnoDB provides transactions, row-level locking, foreign keys, and crash recovery. Official MySQL documentation describes InnoDB as a general-purpose storage engine that balances high reliability and high performance. 5

InnoDB caches table and index data through the buffer pool. Official MySQL documentation states that InnoDB maintains its own buffer pool for caching accessed table and index data in main memory. [7]

4.2 PostgreSQL Storage and WAL

PostgreSQL uses a unified kernel to manage tables, indexes, transactions, and WAL. PostgreSQL uses WAL to support crash recovery, physical replication, archive recovery, and logical replication. PostgreSQL official documentation states that the wal_level parameter determines the amount of information written to WAL. The default value replica supports WAL archiving and replication, including read-only queries on standby servers, while logical adds information required for logical decoding. [8]

4.3 Summary

Dimension	MySQL	PostgreSQL
Storage system	Multiple storage engines	Unified kernel
Default transactional engine	InnoDB	PostgreSQL kernel transaction system
Cache mechanism	InnoDB buffer pool	PostgreSQL shared buffers working with OS cache
WAL/binlog	InnoDB redo log and MySQL binary log	WAL
Storage extensibility	Extended through storage engines and component systems	Extended through extensions, FDW, types, index methods, and more

5. Transaction Isolation and Concurrency Control

5.1 MySQL

InnoDB supports the four transaction isolation levels defined by SQL:1992: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. Official MySQL documentation states that the default InnoDB isolation level is REPEATABLE READ. [9]

InnoDB uses a multi-version mechanism to support consistent non-locking reads. For ordinary SELECT, InnoDB generally uses a consistent read snapshot and does not set locks under isolation levels other than SERIALIZABLE. Under SERIALIZABLE isolation, searches set shared next-key locks on index records encountered. [10]

5.2 PostgreSQL

PostgreSQL official documentation states that the SQL standard defines four isolation levels and describes how PostgreSQL implements them. PostgreSQL's default transaction isolation level is usually READ COMMITTED. [11][12]

The PostgreSQL concurrency control chapter centers on MVCC. PostgreSQL has different snapshot behavior under READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. PostgreSQL official documentation also states that REPEATABLE READ and SERIALIZABLE isolation levels may produce serialization failures, and applications need to be prepared to retry failed transactions. [13]

5.3 Summary

Dimension	MySQL InnoDB	PostgreSQL
Supported isolation levels	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE	READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE; READ UNCOMMITTED is treated as READ COMMITTED
Default isolation level	REPEATABLE READ	READ COMMITTED
Concurrency control	InnoDB MVCC, locks, next-key locks	MVCC, locks, SSI, and more
High-isolation failure handling	Relies on lock waits, deadlock detection, and related mechanisms	REPEATABLE READ / SERIALIZABLE may require handling serialization failures

6. SQL Standard Compatibility

6.1 MySQL

MySQL supports SQL and includes MySQL-specific extensions. The official MySQL documentation includes sections such as MySQL Extensions to Standard SQL, SQL statements, data types, and functions. Some MySQL syntax and behavior have MySQL-specific extension characteristics.

6.2 PostgreSQL

PostgreSQL official documentation includes a SQL Conformance appendix. This appendix states that PostgreSQL's development objective is to conform to the latest official SQL standard where doing so does not contradict traditional features or common sense. It also lists supported and unsupported SQL standard features. [14]

6.3 Summary

Dimension	MySQL	PostgreSQL
SQL support	Supports SQL and MySQL extensions	Supports SQL and PostgreSQL extensions
Official SQL standard description	Documentation includes standard SQL extension descriptions	Documentation includes a SQL Conformance appendix
Dialect characteristics	MySQL-specific syntax and functions are common	PostgreSQL has rich types, functions, operators, and extension mechanisms

7. Data Types and JSON Capabilities

7.1 MySQL JSON

MySQL supports a JSON data type and provides JSON functions and operators. Indexing MySQL JSON fields usually relies on generated columns, functional indexes, or related mechanisms. In the official MySQL documentation, the JSON data type, JSON search functions, generated column indexes, and indirect indexing of JSON columns are documented as separate capabilities. [15]

7.2 PostgreSQL JSON and JSONB

PostgreSQL supports json and jsonb types. PostgreSQL official documentation states that GIN indexes can be used to efficiently search keys or key-value pairs in large numbers of jsonb documents, and provides different GIN operator classes for different performance and flexibility tradeoffs. [16]

PostgreSQL also provides JSON functions, JSON paths, JSON constructors, JSON query functions, JSONB containment and existence operators, and other capabilities. PostgreSQL stores jsonb internally in binary form to support indexing and query operations.

7.3 Summary

Dimension	MySQL	PostgreSQL
JSON type	Supports JSON type	Supports json and jsonb
JSON query	Provides JSON functions and operators	Provides JSON/JSONB functions, operators, and JSON path
JSON indexes	Commonly implemented through generated columns, functional indexes, or related mechanisms	JSONB can use GIN indexes
Semi-structured data	Supports JSON storage and queries	Supports JSON/JSONB with richer indexing capabilities

8. Indexing Systems

8.1 MySQL

MySQL supports B-tree, FULLTEXT, SPATIAL, and other index types, with specific capabilities affected by the storage engine. InnoDB supports clustered primary-key indexes and secondary indexes. Official MySQL documentation separately describes secondary indexes, generated column indexes, spatial indexes, full-text indexes, and related capabilities.

MySQL provides query execution plan information through EXPLAIN. Official MySQL documentation states that EXPLAIN can show how MySQL executes statements and supports traditional tabular format, JSON format, and TREE format. [17]

8.2 PostgreSQL

PostgreSQL official documentation states that PostgreSQL provides B-tree, Hash, GiST, SP-GiST, GIN, BRIN, and bloom extension index types. Different index types use different algorithms and are suitable for different indexable conditions. By default, CREATE INDEX creates a B-tree index. [18]

PostgreSQL's indexing system is closely integrated with its extension mechanism. For example, GIN is used for searching elements inside composite values, and official documentation uses documents containing specific terms as an example. [19]

8.3 Summary

Dimension	MySQL	PostgreSQL
Common default index	B-tree	B-tree
JSON-related indexes	Generated columns, functional indexes, and similar paths	JSONB + GIN
Multiple index types	Supports multiple index types, affected by storage engine	B-tree, Hash, GiST, SP-GiST, GIN, BRIN, bloom
Extensibility	Extended through storage engines, plugins, functions, and related mechanisms	Extended through extensions, index methods, operator classes, and related mechanisms

9. Extension Capabilities

9.1 MySQL

MySQL provides extension mechanisms such as plugins, components, storage engines, and functions. MySQL's storage engine architecture allows different capabilities to be provided by different storage engines. InnoDB is the default transactional engine, while NDB Cluster, MyISAM, and others belong to different storage-engine or related systems.

9.2 PostgreSQL

PostgreSQL official documentation states that PostgreSQL is designed to be easily extensible, and extensions loaded into the database can work like built-in features. CREATE EXTENSION loads an extension into the current database and records the objects it creates so that they can later be removed by DROP EXTENSION. [6][20]

PostgreSQL extensions can create functions, data types, operators, and index support methods. PostgreSQL official documentation also states that extensions can include SQL scripts, control files, and shared libraries built from C code. [20]

9.3 Summary

Dimension	MySQL	PostgreSQL
Extension path	Plugins, components, storage engines, functions	CREATE EXTENSION, types, functions, operators, index methods
Extension object management	Depends on the specific plugin/component mechanism	Extension-created objects can be recorded and managed by the extension system
Ecosystem examples	Common in storage engines, authentication, audit, enterprise components	Common in PostGIS, pgcrypto, FDW, pgvector, and more

10. Replication and High Availability

10.1 MySQL Replication and Group Replication

MySQL replication is based on the binary log. Official MySQL documentation states that MySQL replication is based on the binary log, and failed transactions on the source are not written to the binary log, so they are not sent to replicas. [21]

MySQL Group Replication supports single-primary and multi-primary modes. Official documentation states that the Group Replication mode is a group-level configuration and that the default is single-primary mode. [22] Group Replication fault tolerance is based on a distributed coordination algorithm and requires a majority of members to be active to reach quorum. Official documentation gives the relationship between tolerated failures and node count as n = 2 x f + 1. [23]

10.2 PostgreSQL Physical Replication and Logical Replication

PostgreSQL supports physical replication and logical replication. PostgreSQL official documentation states that logical replication copies data objects and their changes based on replication identity, usually using the primary key as the replication identity. Logical replication differs from physical replication, which uses exact block addresses and byte-by-byte replication. [24]

PostgreSQL official documentation also states that logical replication can replicate data changes at the table level and allows fine-grained control over data replication and security. [24] PostgreSQL uses WAL to support streaming replication, WAL archiving, PITR, and standby servers. [8][25]

10.3 Summary

Dimension	MySQL	PostgreSQL
Common replication basis	Binary log	WAL
High availability mechanisms	Primary-replica replication, Group Replication, InnoDB Cluster, and more	Streaming replication, logical replication, standby, third-party HA management
Multi-primary capability	Group Replication can use multi-primary	Native logical replication can support multi-directional data flows, but conflict handling must be designed architecturally
Replication granularity	Binary log event replication	Physical replication, logical replication, table-level publication/subscription
Quorum mechanism	Group Replication requires a majority	PostgreSQL native replication itself is not equivalent to built-in consensus cluster management

11. Backup and Recovery

11.1 MySQL

Official MySQL documentation provides logical backup methods such as mysqldump. The documentation states that mysqldump can export a database to SQL files, and that the mysql client can import them on another server. [26]

MySQL also supports replication-based snapshot initialization, binary logs, enterprise backup tools, and other backup approaches. Different backup methods relate to recovery objectives, data volume, downtime requirements, and replication topology.

11.2 PostgreSQL

PostgreSQL official documentation divides backup methods into three categories: SQL dump, file system level backup, and continuous archiving. Official documentation also states that pg_dump output can normally be reloaded into newer versions of PostgreSQL, while file-level backup and continuous archiving are more strongly tied to server versions. [27]

PostgreSQL continuous archiving and Point-in-Time Recovery depend on continuously archived WAL files. Official documentation states that successful recovery using continuous archiving requires a continuous sequence of archived WAL files, at least covering the interval after the backup starts. [28]

11.3 Summary

Dimension	MySQL	PostgreSQL
Logical backup	mysqldump	pg_dump
Physical backup	Physical files, enterprise backup tools, replication snapshots, and more	File system level backup, pg_basebackup
Point-in-time recovery	Combined with binary logs and backup strategy	Continuous archiving + WAL + PITR
Cross-version migration	Depends on dump/restore and compatibility	pg_dump output is usually suitable for reloading into newer versions

12. Security Capabilities

12.1 MySQL

MySQL supports users, privileges, roles, authentication plugins, TLS encrypted connections, and password management. Official MySQL documentation states that MySQL supports multiple TLS protocols and ciphers and allows configuration of protocols and ciphers available for encrypted connections. [29]

Official MySQL documentation also states that roles can affect session privileges. Session privileges come from privileges directly granted to the account and from the privileges of currently active roles. [30]

12.2 PostgreSQL

PostgreSQL supports roles, privileges, pg_hba.conf client authentication control, SSL encrypted connections, row-level security, and extension-based encryption capabilities. PostgreSQL official documentation states that client authentication is controlled by pg_hba.conf. [31] PostgreSQL also natively supports SSL connections to encrypt client-server communication. [32]

PostgreSQL provides some cryptographic capabilities through extensions. For example, pgcrypto is one of the official supplied modules, provides cryptographic functions, and depends on OpenSSL. [33]

12.3 Summary

Dimension	MySQL	PostgreSQL
Users and privileges	Users, privileges, roles	Roles, privileges, authentication rules
Connection encryption	Supports TLS protocol and cipher configuration	Supports SSL connections
Authentication	Authentication plugins, password management	pg_hba.conf, authentication methods, role system
Encryption extensions	Enterprise components, functions, and plugins	Extensions such as pgcrypto

13. Operations and Maintenance Characteristics

13.1 MySQL

MySQL operations usually involve InnoDB buffer pool, redo log, binary log, replication lag, indexes, slow queries, connection counts, lock waits, backup and recovery, and version upgrades. Official MySQL documentation provides observation entry points such as Performance Schema, Information Schema, EXPLAIN, and replication status variables.

MySQL InnoDB table, index, and transaction lock information can be observed through related system tables and Performance Schema. Official MySQL documentation states that one INFORMATION_SCHEMA table and two Performance Schema tables can be used to monitor InnoDB transactions and diagnose potential locking problems. [34]

13.2 PostgreSQL

PostgreSQL operations usually involve VACUUM, autovacuum, WAL, checkpoints, replication slots, statistics, query plans, index bloat, connection counts, backup archiving, and more. PostgreSQL official documentation states that PostgreSQL databases require periodic maintenance, namely vacuuming. In many installations, using the autovacuum daemon is sufficient for vacuuming, but autovacuum parameters may need tuning for better results. [35]

PostgreSQL provides runtime status information through pg_stat_* views. Official documentation states that pg_stat_ssl shows SSL usage for each backend or WAL sender process and can be joined with pg_stat_activity or pg_stat_replication. [36]

13.3 Summary

Dimension	MySQL	PostgreSQL
Common maintenance focus	Buffer pool, binlog, replication, lock waits, slow queries, indexes	VACUUM, WAL, checkpoint, replication slot, statistics, index bloat
Query analysis	EXPLAIN, EXPLAIN ANALYZE, Performance Schema	EXPLAIN, EXPLAIN ANALYZE, pg_stat_*
Storage maintenance	InnoDB internal mechanisms and tablespace management	VACUUM / autovacuum are key maintenance mechanisms
Replication maintenance	Binary log, replica, Group Replication	WAL, replication slot, standby, logical replication

14. Database Suitability for Configuration-Center-Like Systems

Configuration-center-like systems usually contain configuration definitions, configuration content, scopes, release versions, approval records, audit logs, canary rules, and permission relationships. These data have clear structured relationships, transaction consistency requirements, and audit-query needs. Both MySQL and PostgreSQL can be used as the primary database for a configuration center. Both support transactions, indexes, backup and recovery, replication, and secure connections.

For small text configuration such as YAML, properties, JSON, XML, and TOML, MySQL can store content in TEXT / MEDIUMTEXT, while PostgreSQL can use text. For JSON configuration, MySQL provides a JSON type and related functions. PostgreSQL provides both json and jsonb, and supports JSONB GIN indexes. For large files, binary files, large rule packages, or model files, neither system is an object storage system. It is usually necessary to use object storage or a file service to store the content body, while the relational database stores URI, checksum, size, version, format, and release metadata.

From official capability descriptions, MySQL has complete materials around common enterprise OLTP, primary-replica replication, Group Replication, toolchains, and usage experience. PostgreSQL has richer built-in descriptions around object-relational modeling, extension mechanisms, index types, JSONB, logical replication, and SQL standard conformance. Whether a configuration-center-like system should use MySQL or PostgreSQL ultimately depends on the existing operations system, team technology stack, deployment environment, audit requirements, JSON query complexity, extension needs, and high-availability strategy.

15. Comprehensive Comparison Table

Dimension	MySQL	PostgreSQL
Database type	Relational database management system	Object-relational database system
License	MySQL Community Edition uses GPL	PostgreSQL License, similar to BSD/MIT
Default transaction mechanism	InnoDB	PostgreSQL kernel transaction system
Default isolation level	REPEATABLE READ	READ COMMITTED
MVCC	InnoDB multi-version mechanism	PostgreSQL MVCC
JSON	JSON type, functions, generated columns / functional indexes	json, jsonb, JSONB GIN indexes
Index types	B-tree, FULLTEXT, SPATIAL, and more	B-tree, Hash, GiST, SP-GiST, GIN, BRIN, bloom
Extensibility	Plugins, components, storage engines	CREATE EXTENSION, types, functions, operators, index methods
Replication basis	Binary log	WAL
High availability	Primary-replica replication, Group Replication, InnoDB Cluster, and more	Streaming replication, logical replication, standby, third-party HA management
Backup	mysqldump, physical backup, enterprise backup tools, and more	pg_dump, file-level backup, continuous archiving, pg_basebackup
Secure connection	TLS	SSL
Operational focus	InnoDB, binlog, replication, locks, slow queries	VACUUM, WAL, replication slots, statistics, index bloat

16. Conclusion

Based on official documentation, MySQL and PostgreSQL are both mature open-source relational database systems. Both provide transactions, indexes, replication, backup, secure connections, and operational observability. MySQL uses InnoDB as its default transactional storage engine and supports common enterprise OLTP and high-availability scenarios through binary log, replication, Group Replication, roles, TLS, and the MySQL toolchain. PostgreSQL is positioned as an object-relational database and provides capabilities through MVCC, WAL, json/jsonb, index types such as GIN/GiST/BRIN, CREATE EXTENSION, logical replication, continuous archiving, and rich system views.

In configuration-center-like metadata systems, both can satisfy storage requirements for structured metadata, version records, release audit, and permission relationships. Their differences mainly lie in JSON query capabilities, extension mechanisms, default isolation levels, replication models, high-availability implementation paths, and existing operations systems. Relational databases are suitable for storing configuration definitions, versions, audit records, and small text configuration. Large files, binary files, and very large rule packages should not be stored long-term as large fields in primary database tables. Their content bodies should be stored in object storage or file services, while the database stores references and metadata.

References

1 MySQL Community Edition official description. 2 MySQL Releases: Innovation and LTS official documentation. 3 PostgreSQL About official description. 4 PostgreSQL License official description. 5 MySQL InnoDB official documentation. [6] PostgreSQL Extension official documentation. [7] MySQL InnoDB Buffer Pool official documentation. [8] PostgreSQL WAL and replication configuration official documentation. [9] MySQL InnoDB Transaction Isolation Levels official documentation. [10] MySQL InnoDB Locks and Consistent Read official documentation. [11] PostgreSQL Transaction Isolation official documentation. [12] PostgreSQL SET TRANSACTION official documentation. [13] PostgreSQL Serialization Failure Handling official documentation. [14] PostgreSQL SQL Conformance official documentation. [15] MySQL JSON and generated column index official documentation. [16] PostgreSQL JSON Types official documentation. [17] MySQL EXPLAIN official documentation. [18] PostgreSQL Index Types official documentation. [19] PostgreSQL GIN Indexes official documentation. [20] PostgreSQL CREATE EXTENSION official documentation. [21] MySQL InnoDB and MySQL Replication official documentation. [22] MySQL Group Replication Single-Primary and Multi-Primary Modes official documentation. [23] MySQL Group Replication Fault Tolerance official documentation. [24] PostgreSQL Logical Replication official documentation. [25] PostgreSQL High Availability, Load Balancing, and Replication official documentation. [26] MySQL mysqldump official documentation. [27] PostgreSQL Backup and Restore official documentation. [28] PostgreSQL Continuous Archiving and PITR official documentation. [29] MySQL Encrypted Connection TLS Protocols and Ciphers official documentation. [30] MySQL Account Categories and Roles official documentation. [31] PostgreSQL pg_hba.conf official documentation. [32] PostgreSQL SSL Connections official documentation. [33] PostgreSQL pgcrypto official documentation. [34] MySQL InnoDB Transaction and Locking Information official documentation. [35] PostgreSQL Routine Vacuuming official documentation. [36] PostgreSQL Monitoring Statistics official documentation.

Version statements in this article are based on the official MySQL 8.4 Reference Manual and PostgreSQL current documentation pages. The official MySQL documentation states that the 8.4 Reference Manual covers the MySQL 8.4 series, and the PostgreSQL official documentation page shows the current online version as 18. (MySQL Developer Zone)

The project positioning and licensing sections are based on the official MySQL Community Edition page, MySQL release model documentation, PostgreSQL About page, and PostgreSQL License page. The official MySQL Community Edition page states that it uses GPL, the MySQL release model describes the LTS and Innovation tracks, PostgreSQL officially describes itself as an object-relational database system, and the PostgreSQL License page states that its license is similar to BSD/MIT. (MySQL)

The transaction, concurrency, and storage sections are based on MySQL InnoDB, transaction isolation, locking, and PostgreSQL transaction isolation, MVCC, and WAL documentation. MySQL InnoDB's default isolation level is REPEATABLE READ, while PostgreSQL's default is usually READ COMMITTED. (MySQL Developer Zone)

The JSON, index, and extension sections are based on MySQL JSON/generated column index documentation and PostgreSQL JSONB/GIN/index type/CREATE EXTENSION documentation. PostgreSQL official documentation lists index types such as B-tree, Hash, GiST, SP-GiST, GIN, BRIN, and bloom, and states that GIN can be used for JSONB key or key-value searches. (MySQL Developer Zone)

The replication, high availability, backup, and security sections are based on MySQL replication, Group Replication, TLS, and role documentation, as well as PostgreSQL logical replication, streaming replication, backup, PITR, pg_hba.conf, and SSL documentation. (MySQL Developer Zone)

Chinese Reference

• Read the original Chinese article