做上位机时该选哪个数据库？SQLite3 / MySQL / PostgreSQL / MongoDB 深度对比

工业上位机软件在数据存储层面面临着独特的挑战：既要应对高频采集的实时数据，又要保证历史记录的可靠持久化，还要兼顾现场部署的运维成本。当你打开数据库选型清单，SQLite3、MySQL、PostgreSQL、MongoDB 是出现频率最高的四个名字——但每一个都有截然不同的适用场景。本文从上位机开发的实际视角出发，系统梳理四者的核心差异，并给出可落地的选型建议。

上位机数据存储的典型需求

在正式比较之前，先明确上位机系统对数据库的典型诉求：

高频写入：PLC 或传感器数据采集周期通常在 100ms ～ 1s 级别，单节点日写入量可达百万条以上。 时序查询：最常见的查询是"最近 N 条"或"时间范围聚合"，而非复杂关联查询。 离线可用：工厂内网或单机部署场景下，数据库必须本地自治，无需依赖外部服务。 数据结构多样：既有规整的模拟量/数字量，也可能有 JSON 格式的报警记录、配方参数、设备档案。 * 运维轻量：现场工程师不是 DBA，部署、备份、迁移必须尽量简单。

带着这些约束，我们来逐一审视四个数据库。

SQLite3

核心定位

SQLite3 是一个嵌入式关系型数据库，整个引擎就是一个 .dll / .so 库文件，数据以单文件形式存储在磁盘上。它没有独立的服务进程，应用直接通过库调用读写数据库文件。

优点

缺点

适用场景

最适合：

单机 SCADA、HMI 软件的本地历史数据存储 配方管理、设备参数配置文件 离线缓存队列（数据采集后批量上传云端前的本地缓冲） 工控平板、工控机等资源受限设备

MySQL

核心定位

MySQL 是最广泛使用的开源关系型数据库，采用 C/S 架构，需要独立的服务进程。长期被 LAMP 栈统治 Web 领域，在国内工业软件中也有大量存量应用。

优点

缺点

适用场景

最适合：

中小型 MES/WMS 系统，多台上位机共享一个数据库服务器 已有 MySQL 运维体系的工厂 IT 环境 设备台账、工单管理、用户权限等业务型数据 需要 Web 管理界面或报表系统，团队熟悉 MySQL 生态

PostgreSQL

核心定位

PostgreSQL（PG）是功能最全面的开源关系型数据库，以严格的 SQL 标准兼容性、强大的扩展机制和丰富的数据类型著称。它在复杂查询、JSON 处理、地理空间数据等高级场景下显著优于 MySQL。

优点

TimescaleDB 时序能力示例

借助 TimescaleDB，PostgreSQL 可以直接承担工业时序数据的存储：

创建一张时序表仅需：

-- 创建普通表
CREATE TABLE sensor_data (
    time        TIMESTAMPTZ NOT NULL,
    device_id   TEXT        NOT NULL,
    tag_name    TEXT        NOT NULL,
    value       DOUBLE PRECISION,
    quality     SMALLINT DEFAULT 192
);

-- 转换为 hypertable（自动按时间分区）
SELECT create_hypertable('sensor_data', 'time');

-- 创建连续聚合：每分钟均值
CREATE MATERIALIZED VIEW sensor_1min
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 minute', time) AS bucket,
    device_id,
    tag_name,
    AVG(value)  AS avg_val,
    MAX(value)  AS max_val,
    MIN(value)  AS min_val
FROM sensor_data
GROUP BY bucket, device_id, tag_name;

缺点

适用场景

最适合：

需要时序数据 + 业务数据统一存储（装了 TimescaleDB 后"一库两用"） 复杂报表、统计分析、质量追溯系统 有 GIS 需求的系统（设备地图、厂区路由） 数据结构需要灵活演进（JSONB 处理半结构化数据） * 新项目、新团队，优先推荐作为关系型数据库首选

MongoDB

核心定位

MongoDB 是文档型 NoSQL 数据库，以 BSON（类 JSON）文档为存储单元，天然适合结构不固定、嵌套层级深的数据。它没有预定义 Schema，字段可随时增减。

优点

缺点

典型文档结构示例

{
  "_id": "evt_20240315_001",
  "timestamp": "2024-03-15T08:32:11Z",
  "device": {
    "id": "PLC_LINE_A_01",
    "name": "A线主控 PLC",
    "location": "车间A-东"
  },
  "alarm": {
    "code": "E4021",
    "level": "HIGH",
    "description": "电机温度超限",
    "threshold": 85.0,
    "actual": 91.3
  },
  "context": {
    "operator": "张伟",
    "shift": "早班",
    "production_order": "PO20240315003"
  },
  "ack": {
    "acknowledged": true,
    "acked_by": "李明",
    "acked_at": "2024-03-15T08:35:22Z"
  }
}

适用场景

最适合：

报警管理系统（报警结构复杂、字段因设备类型不同而差异大） 设备档案管理（不同类型设备的属性字段差异巨大） 生产日志、操作审计（写多读少，结构灵活） 配合微服务架构，作为独立的文档存储服务

综合对比

选型决策树

实战组合方案

在实际上位机项目中，单一数据库往往无法覆盖所有场景。以下是两种常见的组合策略：

方案 A：SQLite3 + PostgreSQL（边缘 + 云端）

适合网络不稳定、需要断点续传的工厂现场。边缘 SQLite3 保证数据不丢失，中心 PostgreSQL 承担历史分析。

方案 B：PostgreSQL + MongoDB（结构化 + 非结构化）

适合功能复杂的 MES 类系统，各取所长，避免"用锤子看什么都是钉子"。

总结

没有"最好"的数据库，只有"最合适"的选择：

单机 HMI / 工控机 / 离线部署 → SQLite3，首选无服务嵌入式方案 多客户端共享、熟悉关系型、注重生态 → MySQL，稳健的中间选择 新项目、时序 + 业务数据一体化、复杂查询 → PostgreSQL，综合能力最强的关系型 报警/日志/档案等 Schema 复杂多变 → MongoDB，文档模型天然契合

最后一个实用建议：如果你在做一个新的上位机项目，不确定从哪里开始，先从 SQLite3 起步——它会让你在原型阶段飞速迭代；当数据规模增长或多用户并发需求出现时，再迁移到 PostgreSQL。这条路径风险最低，且两者的 SQL 方言差异极小，迁移成本可控。

关键词：上位机数据库, SQLite3, MySQL, PostgreSQL, MongoDB, 工业数据存储, TimescaleDB, 数据库选型