本文系统梳理四款主流数据库的定位、核心特性、差异边界与适用场景，覆盖关系型与 NoSQL、服务端与嵌入式、磁盘存储与内存存储四大维度，可作为技术选型知识库归档。

一、PostgreSQL 完整介绍

1.1 基础定位

PostgreSQL（常简称 PG）是一款开源的对象 - 关系型数据库管理系统（ORDBMS），起源于加州大学伯克利分校的 Ingres 项目，拥有超过 40 年的研发历史，是目前功能最强大、SQL 标准兼容度最高的开源关系型数据库。

它遵循 PostgreSQL License（类 BSD 宽松协议），可免费商用、修改、二次分发，无开源传染风险，是企业级复杂业务的首选开源关系库。

1.2 核心特性

1. 极致的 SQL 标准兼容支持几乎所有 SQL:2023 标准特性，包括窗口函数、递归 CTE、物化视图、合并查询、复杂子查询等，语法严谨规范，迁移成本低。

2. 极其丰富的数据类型除基础的数值、字符串、日期外，原生支持：

   • 半结构化：JSON / JSONB（二进制 JSON，支持索引）、XML
   • 复合类型：数组、枚举、范围类型、自定义结构体
   • 专业类型：几何类型、全文检索类型、IP 地址、UUID、货币类型
   • 扩展生态：通过 PostGIS 扩展支持完整的地理空间数据处理，是业界 GIS 系统标配。

3. 强大的查询与计算能力支持多表关联、子查询、窗口函数（排名、累计、分组排序）、递归查询、行级触发器、自定义函数（支持 PL/pgSQL、Python、C 等多种语言）、存储过程，可在数据库内完成复杂逻辑计算。

4. 完善的事务与并发控制完整支持 ACID 特性，基于 MVCC（多版本并发控制）实现读写不阻塞；支持四种事务隔离级别，默认读已提交，可配置可重复读、可串行化；支持行级锁、表级锁、 advisory 锁。

5. 极致的扩展性支持自定义数据类型、操作符、索引类型、聚合函数；内置多种索引：B 树、哈希、GIN（倒排索引，适合数组 / JSON）、GiST（通用搜索树，适合全文 / 地理）、BRIN（块范围索引，适合时序大数据）。

6. 高可用与复制能力支持流复制（主从同步）、逻辑复制（按表 / 行复制）、同步 / 异步复制，可搭建一主多从、读写分离架构；生态中有 Patroni 等工具实现高可用自动故障转移。

1.3 适用场景

• 企业级复杂业务系统，需要严谨的数据结构与复杂查询
• 地理信息系统（GIS）、地图服务（搭配 PostGIS）
• 数据分析、数仓边缘节点、混合负载（OLTP + 轻量 OLAP）
• 需要自定义数据类型、高级 SQL 特性的特殊业务
• 对开源协议友好度要求高的商业项目

二、另外三款数据库核心概述

2.1 MySQL：最主流的通用关系型数据库

MySQL 是 Oracle 旗下开源关系型数据库，采用双授权模式（GPL 开源 + 商业授权），是全球使用率最高的数据库，互联网行业事实标准。

• 核心优势：轻量易用、生态极其成熟、社区庞大、运维成本低、高并发 OLTP 性能优秀；InnoDB 存储引擎支持事务、行级锁、外键。
• 核心定位：面向业务交易型场景（OLTP），主打高性能、高可用、易上手。
• 典型场景：电商、社交、后台管理系统、互联网业务主库。

2.2 SQLite：嵌入式零配置文件型关系库

SQLite 是一款嵌入式、零服务、单文件的关系型数据库引擎，用 C 语言编写，体积仅几百 KB，不需要独立的服务器进程，整个数据库就是一个磁盘文件。

• 核心优势：零部署、零配置、跨平台、体积极小、资源占用极低；原生支持事务 ACID。
• 核心局限：写操作是库级锁，并发写入能力差；不支持网络远程访问，只能本地读写；无用户权限体系。
• 典型场景：移动端 App、桌面软件、嵌入式设备、小型工具、浏览器本地存储、单元测试。

2.3 Redis：高性能内存键值 NoSQL 数据库

Redis（Remote Dictionary Server）是开源的内存型键值 NoSQL 数据库，主打极致性能与丰富数据结构，是业界缓存与实时数据场景的标配。

• 核心优势：纯内存操作，单线程模型，QPS 可达十万级；支持字符串、哈希、列表、集合、有序集合、位图、流等多种数据结构；支持 RDB/AOF 两种持久化方式；内置发布订阅、事务、Lua 脚本、集群、哨兵高可用。
• 核心局限：受内存容量限制，不适合存储海量冷数据；复杂查询能力弱，不支持 SQL。
• 典型场景：热点数据缓存、用户会话存储、排行榜、实时计数、限流、消息队列、分布式锁。

三、四者横向详细对比

3.1 核心维度总表

表格

3.2 关键差异深度解析

1. 数据模型与查询能力

• PostgreSQL：功能天花板，关系型能力最全面，同时原生支持 JSONB、数组、地理数据等，复杂查询、分析查询能力最强。
• MySQL：侧重事务型业务查询，语法更灵活宽松，复杂分析能力弱于 PG，适合简单 CRUD 为主的业务。
• SQLite：支持基础 SQL、联表、事务，但不支持存储过程、触发器、用户权限，适合简单本地数据存储。
• Redis：无 SQL 能力，只能通过 key 操作数据，擅长单维度高速读写，不适合复杂关联查询。

2. 架构与部署方式

• PG / MySQL / Redis：都是「客户端 - 服务端」架构，数据库作为独立服务运行，支持网络远程访问，多客户端共享。
• SQLite：无服务端，直接嵌入到应用程序中，数据库就是一个普通文件，应用直接读写文件，无法远程访问。

3. 并发与性能表现

• 读性能：Redis > MySQL ≈ PostgreSQL > SQLite
• 写性能：Redis（内存）> MySQL ≈ PostgreSQL > SQLite
• 并发写入：PostgreSQL 与 MySQL（InnoDB）均为行级锁，支持高并发写入；SQLite 写操作会锁整个库，只适合低并发场景；Redis 单线程无锁，写入性能最高但受内存限制。

4. 事务与一致性

• 三款关系库都支持 ACID，但粒度不同：
  • PG、MySQL（InnoDB）是行级锁，并发事务互不影响；
  • SQLite 是库级锁，写操作会阻塞所有其他读写，并发事务能力弱。
• Redis 不支持传统数据库事务，只能通过 Lua 脚本保证一批操作的原子性，一致性级别更低，主打高性能而非强一致。

5. 扩展性与高级功能

• PostgreSQL 的扩展性遥遥领先：自定义类型、索引、函数，加上丰富的第三方扩展（PostGIS、TimescaleDB 时序、Citus 分布式等），适配几乎所有场景。
• MySQL 依赖存储引擎扩展，生态成熟但深度不如 PG。
• Redis 支持模块扩展（如 RediSearch、RedisJSON），但核心定位仍是轻量高速。
• SQLite 几乎无扩展能力，功能固定。

6. 运维与成本

• SQLite 零运维，直接使用，成本最低。
• Redis 运维简单，监控、备份成熟，成本低。
• MySQL 生态工具最丰富，运维门槛低，人力成本适中。
• PostgreSQL 功能多、配置项多，深度调优门槛更高，人力成本略高。

四、四者之间的联系与组合用法

4.1 共性联系

1. 核心目标一致：都是数据持久化存储系统，解决「数据存、读、查、管」的核心问题。
2. 都支持结构化数据：PG、MySQL、SQLite 都是关系型，支持 SQL 表结构；Redis 也可通过哈希、有序集合存储结构化数据。
3. 生态互通：都支持所有主流编程语言（Python、Java、Go、C++ 等），都有成熟的 ORM、客户端工具。
4. 均支持事务：四款数据库都在不同程度上支持事务原子性，只是强度和粒度不同。

4.2 典型组合使用场景

真实项目中很少只使用一种数据库，通常是「分层存储」组合：

1. MySQL + Redis：最经典的互联网架构

   • MySQL 存储核心业务数据（用户、订单、商品），保证数据持久化与强一致；
   • Redis 缓存热点数据（商品详情、用户信息）、存储会话、做限流与计数器，扛高并发。

2. PostgreSQL + Redis：企业级复杂业务架构

   • PG 存储复杂业务数据、地理数据、做轻量分析；
   • Redis 负责高并发读写场景的缓存与实时计算。

3. 服务端 MySQL/PG + 客户端 SQLite：端云协同

   • 服务端用 MySQL/PG 存全量数据；
   • 移动端 / 桌面端用 SQLite 存本地离线数据，联网时同步到服务端。

4. PostgreSQL + SQLite + Redis：全链路分层 PG 做主库与分析、Redis 做缓存加速、SQLite 做边缘 / 本地存储，各司其职。

五、选型决策指南

表格

一句话总结

• 存核心复杂业务、追求功能深度→ PostgreSQL
• 做通用互联网业务、追求生态与易用→ MySQL
• 做本地嵌入式存储、追求零部署→ SQLite
• 扛高并发热点、追求极致性能→ Redis