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.
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/openHaloWhy 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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
