Databases 11 min read

Why Top Companies Prefer PostgreSQL Over MySQL: A Deep Technical Comparison

The article examines why leading Chinese tech firms are increasingly adopting PostgreSQL instead of MySQL, detailing PostgreSQL‑based products, comparing data‑type support, sequence handling, extensions, monitoring tools, replication mechanisms, licensing, community openness, and MVCC implementation, while also outlining MySQL's limitations.

Top Architect
Top Architect
Top Architect
Why Top Companies Prefer PostgreSQL Over MySQL: A Deep Technical Comparison

Background

With the push for domestic innovation and the need for autonomous, controllable databases, PostgreSQL has become the preferred open‑source foundation for many Chinese enterprises because of its stability, rich feature set, and strong community support.

PostgreSQL‑based solutions in China

Tencent TBase – https://github.com/Tencent/TBase Alibaba Cloud PolarDB for PostgreSQL – commercial service built on PostgreSQL

Huawei GaussDB (openGauss) – partially compatible with the PostgreSQL ecosystem, adds columnar storage and AI optimizer https://opengauss.org openHalo – open‑source distributed HTAP platform

https://github.com/HaloTech-Co-Ltd/openHalo

Why enterprises choose PostgreSQL over MySQL

Richer data types : PostgreSQL supports ARRAY, range types (int4range, tsrange), composite types, and JSONB with indexing, enabling complex data modeling.

Native sequence objects : PostgreSQL provides true SEQUENCE objects that can be used independently of tables, e.g.:

-- PostgreSQL create independent sequence
CREATE SEQUENCE order_seq START WITH 1 INCREMENT BY 1;
INSERT INTO orders (id, name) VALUES (nextval('order_seq'), 'test');

MySQL lacks a comparable standalone sequence and must simulate it with AUTO_INCREMENT or user‑defined variables.

Extensible ecosystem : extensions such as TimescaleDB (time‑series), pg_trgm (fuzzy search), Citus (distributed), and pg_stat_statements (SQL monitoring) are readily installable.

Built‑in monitoring views : pg_stat_activity, pg_stat_statements, pg_locks, and EXPLAIN ANALYZE provide detailed runtime insights without extra tools.

Mature third‑party tooling : PgAdmin, pg_stat_monitor, and seamless Prometheus + Grafana integration simplify operations.

Open licensing : PostgreSQL uses a BSD‑like license, fully free of commercial restrictions, unlike MySQL’s GPL + commercial dual‑license.

Active community : Global contributors ensure transparent development, extensive documentation, and abundant debugging resources.

MySQL’s limitations

Less expressive data types : No native ARRAY, range, or composite types; JSON fields cannot be indexed efficiently.

No true sequence support : Sequences are simulated via AUTO_INCREMENT, which cannot be shared across tables and complicates distributed uniqueness.

Fewer extensions : The ecosystem lacks the breadth of PostgreSQL extensions, limiting advanced use cases.

Monitoring gaps : Tools like Performance Schema and slow_query_log require complex configuration and lack the visual integration of PgAdmin or DBeaver.

Replication model : MySQL’s asynchronous replication behaves more like a backup mechanism, with risks of data loss and limited GTID reliability; synchronous or semi‑synchronous modes need extra setup.

License and community : GPL + commercial licensing controlled by Oracle, with a community that is less open than PostgreSQL’s.

PostgreSQL is a “programmable database” that can be treated as an application platform, whereas MySQL functions more like an execution engine.

Feature‑by‑feature comparison

License : MySQL – GPL + commercial; PostgreSQL – BSD‑like, fully free.

Enterprise vs. community edition : MySQL’s enterprise edition adds features such as auditing and encryption; PostgreSQL’s community edition includes the full feature set.

Source transparency : MySQL development is Oracle‑driven; PostgreSQL is governed by a global foundation.

Long‑term stability : MySQL’s roadmap can be influenced by corporate decisions; PostgreSQL’s development is community‑driven and independent.

MVCC implementation differences

PostgreSQL stores multiple row versions directly in the heap, providing true snapshot isolation and allowing readers to see a consistent view while writers modify data.

MySQL’s InnoDB keeps only the current version in the table and stores older versions in the undo log, which can lead to faster reads but may cause undo‑log bloat for long transactions.

MySQL’s replication is more akin to a “backup mechanism”, while PostgreSQL’s streaming and logical replication are integral parts of a high‑availability architecture.

Conclusion

PostgreSQL is better suited for systems that require long‑term evolution, complex data models, and strong consistency, whereas MySQL remains a fast‑to‑deploy solution for read‑heavy, simple web applications. The rise of domestic databases in China builds on PostgreSQL’s open‑source foundation to achieve independent innovation.

SQLMySQLOpen SourcePostgreSQLDatabase comparison
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.