文章目录
-
- 一、核心本质差异：运行模型完全不同
-
- [1.1 SQLite：进程内嵌入式运行，直读本地文件](#1.1 SQLite：进程内嵌入式运行，直读本地文件)
- [1.2 MySQL/PostgreSQL：独立服务器模型，网络交互运行](#1.2 MySQL/PostgreSQL：独立服务器模型，网络交互运行)
- [二、网络服务能力对比：无端口 vs 端口监听](#二、网络服务能力对比：无端口 vs 端口监听)
-
- [2.1 SQLite：无网络、无端口、无服务](#2.1 SQLite：无网络、无端口、无服务)
- [2.2 MySQL/PostgreSQL：常驻网络服务](#2.2 MySQL/PostgreSQL：常驻网络服务)
- [三、用户与权限体系：无账号体系 vs 完善角色权限](#三、用户与权限体系：无账号体系 vs 完善角色权限)
-
- [3.1 SQLite：无内置账号、无角色系统](#3.1 SQLite：无内置账号、无角色系统)
- [3.2 MySQL/PostgreSQL：完整权限体系](#3.2 MySQL/PostgreSQL：完整权限体系)
- [四、部署与权限成本对比：零配置 vs 重运维](#四、部署与权限成本对比：零配置 vs 重运维)
-
- [4.1 SQLite：极致轻量化，部署零成本](#4.1 SQLite：极致轻量化，部署零成本)
- [4.2 MySQL/PostgreSQL：部署复杂，运维成本高](#4.2 MySQL/PostgreSQL：部署复杂，运维成本高)
- 五、核心并发机制差异（重中之重）
-
- [5.1 SQLite：读多写单，写独占机制](#5.1 SQLite：读多写单，写独占机制)
- [5.2 MySQL/PostgreSQL：高并发读写模型](#5.2 MySQL/PostgreSQL：高并发读写模型)
- 六、核心差异汇总表
- 七、最终选型总结
标签：SQLite、数据库对比、MySQL、PostgreSQL、后端存储选型、数据库原理
前言
在日常开发中，很多新手会产生一个误区：只要能执行SQL，数据库就是一样的。因此经常随意混用 SQLite、MySQL、PostgreSQL，导致线上并发报错、权限失控、部署异常、性能瓶颈等一系列问题。
事实上，三者虽然都支持标准SQL语法、都属于关系型数据库，但底层运行模型完全不同。SQLite 是嵌入式本地数据库，MySQL、PostgreSQL 是典型的服务器数据库，二者的工作机制、权限体系、网络模型、并发策略、部署成本有着本质鸿沟。
本文将从运行模型、网络服务、用户权限、部署成本、并发机制五个核心维度，深度拆解 SQLite 与服务端数据库的核心差异，帮你彻底搞懂不同数据库的底层定位，实现精准技术选型。
一、核心本质差异：运行模型完全不同
这是 SQLite 和 MySQL、PostgreSQL 最根本的区别，也是所有差异的源头。看似都是执行SQL、读写数据表，但数据交互链路天差地别。
1.1 SQLite：进程内嵌入式运行，直读本地文件
SQLite 没有独立服务进程，不占用端口、不监听网络，它是以代码库的形式嵌入在我们的应用程序内部运行。应用程序读写数据库，无需经过网络、无需连接服务，直接调用本地 SQLite 库操作本地 db 文件。
SQLite 完整调用链路：
应用 → 本地SQLite库 → 本地数据库文件
整个数据读写过程全部在当前应用进程内完成，无网络开销、无跨进程通信，本地读写速度极快，完全依赖本地文件实现数据持久化。
1.2 MySQL/PostgreSQL：独立服务器模型，网络交互运行
MySQL、PostgreSQL 属于标准的客户端-服务器（C/S）架构数据库。数据库独立部署、独立启动后台服务、监听固定端口，完全脱离业务应用运行。
业务应用无法直接读写数据文件，必须通过网络请求连接数据库服务，由数据库服务进程统一操作数据文件。
服务器数据库完整调用链路：
应用 → 网络 → 数据库服务器 → 数据文件
这种架构的核心价值是支持多客户端远程连接、统一服务管控、支持高并发分布式扩展，适配线上服务场景。
二、网络服务能力对比：无端口 vs 端口监听
基于运行模型的差异，二者的网络能力完全不同，也直接决定了适用场景的边界。
2.1 SQLite：无网络、无端口、无服务
SQLite 不监听任何网络端口 ，也不提供远程连接服务。它只能被本机当前应用进程调用，无法对外提供网络访问能力。
这一特性既是优势也是短板：无需担心网络攻击、端口暴露风险，安全性依赖本地环境；但同时完全不支持多设备、多服务器远程共享数据库，天生不适合分布式、多客户端线上业务。
2.2 MySQL/PostgreSQL：常驻网络服务
MySQL 默认监听 3306 端口，PostgreSQL 默认监听 5432 端口，服务持续后台运行，支持局域网、公网多客户端远程连接。
多台应用服务器、多个客户端可以同时连接同一个数据库服务，实现数据共享、统一读写，这是线上业务系统、后台服务、分布式项目的基础能力。
三、用户与权限体系：无账号体系 vs 完善角色权限
很多开发者踩坑的核心点：习惯性用服务端数据库的权限思维看待 SQLite，导致权限管理混乱。
3.1 SQLite：无内置账号、无角色系统
SQLite 完全没有传统数据库的用户账号、密码、角色、授权机制。
它不存在"创建数据库用户、赋予读写权限、分配角色"的操作。只要应用程序可以读取本地数据库文件，就可以完整操作数据库的所有数据，没有内部权限隔离。
3.2 MySQL/PostgreSQL：完整权限体系
服务端数据库内置完善的用户管理、密码认证、角色权限、精细化授权机制。可以创建不同用户，单独分配查询、新增、修改、删除、建表、管理权限，实现多用户权限隔离、最小权限管控，适配多人协作、多系统接入的企业级场景。
四、部署与权限成本对比：零配置 vs 重运维
4.1 SQLite：极致轻量化，部署零成本
SQLite 无需安装服务、无需配置开机自启、无需初始化环境、无需管理进程。只需引入依赖库，指定本地.db文件路径即可直接使用。
但对应的权限控制也非常简单：SQLite 的权限完全依赖操作系统文件权限 + 业务应用逻辑。
谁能读取、修改本地数据库文件，谁就能操作数据，数据库本身无法做内部权限拦截。适合本地单机可信环境，不适合公网暴露、多用户不可信环境。
4.2 MySQL/PostgreSQL：部署复杂，运维成本高
服务端数据库需要安装、初始化、配置端口、设置开机启动、备份策略、权限管控、性能调优。部署和运维成本更高，但具备完善的服务级保障、权限隔离、日志审计、故障恢复能力，适合生产环境长期稳定运行。
五、核心并发机制差异（重中之重）
并发模型是两者选型最关键的技术指标，直接决定业务能否稳定运行。
5.1 SQLite：读多写单，写独占机制
SQLite 的并发模型非常特殊且清晰：支持多读、单写。
同一时刻，可以有无数个线程/进程读取数据库数据，读取互不阻塞；但同一时刻只能有一个写事务在执行数据修改、新增、删除操作。
当一个写操作执行时，其他所有写操作必须排队等待，无法并行写入。这就导致 SQLite 极度适合读多写少场景，完全不适合高频并发写入场景。
5.2 MySQL/PostgreSQL：高并发读写模型
服务端数据库支持完善的事务隔离级别、读写分离、并发锁机制，可以同时支撑大量并发读、并发写请求，能够承载线上大规模用户的高频读写压力，是互联网业务的标准选型。
六、核心差异汇总表
| 对比维度 | SQLite | MySQL/PostgreSQL |
|---|---|---|
| 运行模型 | 嵌入式进程内运行，直读本地文件 | 独立服务器进程，网络C/S架构 |
| 网络端口 | 不监听端口，无网络服务 | 监听固定端口，支持远程连接 |
| 用户权限 | 无账号角色体系，依赖系统文件权限 | 完整用户、密码、角色、授权体系 |
| 部署成本 | 零配置、开箱即用、无需运维 | 需安装部署、配置运维、进程管理 |
| 并发能力 | 多读单写，写操作串行排队 | 支持高并发读写，适配线上业务 |
| 适用场景 | 本地存储、桌面端、移动端、原型项目、低并发读写 | 线上服务、多客户端、高并发、分布式业务 |
七、最终选型总结
1、如果是本地单机场景：桌面软件、移动端存储、本地缓存、小型原型、数据分析、爬虫落地，优先选择 SQLite，轻量化、零部署、低延迟，体验远超重型数据库。
2、如果是线上服务场景：多用户访问、多客户端连接、需要远程读写、高频并发写入、需要权限管控，必须使用 MySQL 或 PostgreSQL，坚决避免使用 SQLite，防止并发锁死、数据异常、服务崩溃。
3、SQL语法一致，底层完全不同：不要因为都支持SQL就混用数据库，运行模型、并发机制、权限体系的差异，是技术选型的核心依据。