本文系统梳理四款主流数据库的定位、核心特性、差异边界与适用场景,覆盖关系型与 NoSQL、服务端与嵌入式、磁盘存储与内存存储四大维度,可作为技术选型知识库归档。
一、PostgreSQL 完整介绍
1.1 基础定位
PostgreSQL(常简称 PG)是一款开源的对象 - 关系型数据库管理系统(ORDBMS),起源于加州大学伯克利分校的 Ingres 项目,拥有超过 40 年的研发历史,是目前功能最强大、SQL 标准兼容度最高的开源关系型数据库。
它遵循 PostgreSQL License(类 BSD 宽松协议),可免费商用、修改、二次分发,无开源传染风险,是企业级复杂业务的首选开源关系库。
1.2 核心特性
极致的 SQL 标准兼容支持几乎所有 SQL:2023 标准特性,包括窗口函数、递归 CTE、物化视图、合并查询、复杂子查询等,语法严谨规范,迁移成本低。
极其丰富的数据类型除基础的数值、字符串、日期外,原生支持:
- 半结构化:
JSON / JSONB(二进制 JSON,支持索引)、XML - 复合类型:数组、枚举、范围类型、自定义结构体
- 专业类型:几何类型、全文检索类型、IP 地址、UUID、货币类型
- 扩展生态:通过 PostGIS 扩展支持完整的地理空间数据处理,是业界 GIS 系统标配。
- 半结构化:
强大的查询与计算能力支持多表关联、子查询、窗口函数(排名、累计、分组排序)、递归查询、行级触发器、自定义函数(支持 PL/pgSQL、Python、C 等多种语言)、存储过程,可在数据库内完成复杂逻辑计算。
完善的事务与并发控制完整支持 ACID 特性,基于 MVCC(多版本并发控制)实现读写不阻塞;支持四种事务隔离级别,默认读已提交,可配置可重复读、可串行化;支持行级锁、表级锁、 advisory 锁。
极致的扩展性支持自定义数据类型、操作符、索引类型、聚合函数;内置多种索引:B 树、哈希、GIN(倒排索引,适合数组 / JSON)、GiST(通用搜索树,适合全文 / 地理)、BRIN(块范围索引,适合时序大数据)。
高可用与复制能力支持流复制(主从同步)、逻辑复制(按表 / 行复制)、同步 / 异步复制,可搭建一主多从、读写分离架构;生态中有 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 核心维度总表
表格
| 对比维度 | PostgreSQL | MySQL | SQLite | Redis |
|---|---|---|---|---|
| 数据库类型 | 对象 - 关系型(ORDBMS) | 关系型(RDBMS) | 嵌入式关系型 | 内存键值 NoSQL |
| 部署架构 | C/S 架构,独立服务端 | C/S 架构,独立服务端 | 嵌入式,无服务端,库即文件 | C/S 架构,独立服务端,内存为主 |
| 查询语言 | 标准 SQL,兼容度极高 | 标准 SQL,部分特性精简 | 标准 SQL,支持大部分基础语法 | 不支持 SQL,使用命令式操作 |
| 数据模型 | 结构化 + 半结构化 + 自定义类型 | 结构化为主,支持 JSON | 结构化为主,支持 JSON | 键值对 + 多种内置数据结构 |
| 事务支持 | 完整 ACID,4 种隔离级别 | InnoDB 支持完整 ACID | 支持 ACID,库级锁 | 支持弱事务(Lua 脚本保证原子性) |
| 并发能力 | 高,MVCC 读写不阻塞,行级锁 | 高,InnoDB 行级锁 | 低,写操作库级排他锁 | 极高,单线程内存操作,无锁竞争 |
| 存储介质 | 磁盘为主,内存缓存 | 磁盘为主,内存缓存 | 磁盘单文件 | 内存为主,支持磁盘持久化 |
| 扩展性 | 极强,自定义类型 / 索引 / 函数 | 一般,依赖存储引擎 | 极弱,无扩展机制 | 较强,支持模块扩展 |
| 运维复杂度 | 中等偏高 | 低,生态工具完善 | 零运维 | 低 |
| 典型容量 | 百 GB ~ 数 TB | 百 GB ~ 数 TB | MB ~ 几十 GB | 几 GB ~ 几百 GB |
| 开源协议 | PostgreSQL License(宽松) | GPLv2(有传染风险) | 公有领域,完全免费 | BSD 协议(宽松) |
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 共性联系
- 核心目标一致:都是数据持久化存储系统,解决「数据存、读、查、管」的核心问题。
- 都支持结构化数据:PG、MySQL、SQLite 都是关系型,支持 SQL 表结构;Redis 也可通过哈希、有序集合存储结构化数据。
- 生态互通:都支持所有主流编程语言(Python、Java、Go、C++ 等),都有成熟的 ORM、客户端工具。
- 均支持事务:四款数据库都在不同程度上支持事务原子性,只是强度和粒度不同。
4.2 典型组合使用场景
真实项目中很少只使用一种数据库,通常是「分层存储」组合:
MySQL + Redis:最经典的互联网架构
- MySQL 存储核心业务数据(用户、订单、商品),保证数据持久化与强一致;
- Redis 缓存热点数据(商品详情、用户信息)、存储会话、做限流与计数器,扛高并发。
PostgreSQL + Redis:企业级复杂业务架构
- PG 存储复杂业务数据、地理数据、做轻量分析;
- Redis 负责高并发读写场景的缓存与实时计算。
服务端 MySQL/PG + 客户端 SQLite:端云协同
- 服务端用 MySQL/PG 存全量数据;
- 移动端 / 桌面端用 SQLite 存本地离线数据,联网时同步到服务端。
PostgreSQL + SQLite + Redis:全链路分层 PG 做主库与分析、Redis 做缓存加速、SQLite 做边缘 / 本地存储,各司其职。
五、选型决策指南
表格
| 场景 | 首选数据库 | 理由 |
|---|---|---|
| 互联网高并发业务、简单 CRUD、团队熟悉度优先 | MySQL | 生态成熟、人才多、运维成本低、性能足够 |
| 复杂业务、GIS 地理信息、数据分析、需要高级 SQL | PostgreSQL | 功能最强、扩展性最好、协议友好 |
| 移动端 / 桌面软件、嵌入式设备、本地工具、零部署 | SQLite | 体积小、零配置、无需服务端 |
| 高并发缓存、实时计数、排行榜、会话、分布式锁 | Redis | 内存级性能、数据结构丰富、延迟极低 |
一句话总结
- 存核心复杂业务、追求功能深度→ PostgreSQL
- 做通用互联网业务、追求生态与易用→ MySQL
- 做本地嵌入式存储、追求零部署→ SQLite
- 扛高并发热点、追求极致性能→ Redis