GIS研习社 GIS研习社
编程与开发 PostGIS POSTGIS是国产数据库?

PostGIS是国产数据库？揭秘核心技术渊源与GIS数据治理能力（附：PG与国产化替代分析）

编程与开发
Dr.GIS
wowwwai GIS研习社 · 工具流程与项目排障

很多做空间数据平台选型的同学都会问：PostGIS是国产数据库？揭秘核心技术渊源与GIS数据治理能力（附：PG与国产化替代分析）。这个问题不能简单回答“是”或“不是”。PostGIS本身不是国产数据库，它是 PostgreSQL 数据库的空间扩展；但在国产化替代项目中，PostGIS 生态、PostgreSQL 兼容数据库以及国产数据库的空间能力，确实经常被放在一起评估。

本文从 GIS 工程落地角度讲清楚三件事：PostGIS 到底是什么、它和 PostgreSQL 以及国产数据库是什么关系、在自然资源、城市治理、WebGIS、时空数据治理项目中应该如何做技术选型。

PostGIS是国产数据库与PostGIS国产化替代关系图
PostGIS、PostgreSQL、国产数据库与GIS数据治理平台之间的关系示意。

引言：PostGIS是国产数据库吗？先给结论

PostGIS不是国产数据库。更准确地说，PostGIS 是 PostgreSQL 的空间数据库扩展，用来让 PostgreSQL 支持空间数据类型、空间索引、空间查询、空间分析函数和坐标处理能力。

如果把数据库比作一套仓库系统，PostgreSQL 是仓库本体，PostGIS 是专门处理地图、地块、道路、管线、网格、影像边界等空间对象的“GIS能力插件”。

因此，在项目汇报或技术方案中，不建议写成“采用国产数据库 PostGIS”。更规范的表述应当是：

  • 采用 PostgreSQL/PostGIS 构建空间数据库能力；
  • 采用兼容 PostgreSQL/PostGIS 生态的数据库方案；
  • 在国产化环境中评估 PostgreSQL 兼容数据库的空间能力；
  • 在信创或国产化替代项目中验证 PostGIS 函数、空间索引和 GIS 软件适配情况。

这个区别很重要。因为“数据库产品归属”和“GIS空间能力兼容”是两个不同层面的事情，混在一起会导致招投标、架构设计、数据迁移和系统验收出现偏差。

背景：为什么GIS项目经常把PostGIS和国产化替代放在一起讨论

在 GIS 项目中，PostGIS 被频繁讨论，不是因为它“国产”，而是因为它在空间数据库领域非常常见，尤其适合中小型到大型的矢量空间数据管理、空间查询和 WebGIS 后端服务。

很多单位过去使用商业 GIS 数据库方案，例如 Oracle Spatial、ArcSDE、企业级地理数据库等。随着开源 GIS 和国产化替代推进，技术团队会自然关注几个问题：

  • 能不能用 PostgreSQL/PostGIS 替代部分商业空间数据库能力？
  • 现有空间数据能不能从 Oracle、SQL Server、文件地理数据库迁移到 PostGIS？
  • 国产数据库是否兼容 PostgreSQL 协议、SQL 语法和 PostGIS 函数？
  • QGIS、GeoServer、ArcGIS Pro、GDAL、FME、Python GIS 能不能正常连接？
  • 空间索引、坐标系、拓扑检查、叠加分析等能力是否满足生产要求？

这也是“PostGIS是国产数据库”这个疑问产生的根源：很多国产化项目确实会参考 PostgreSQL/PostGIS 的技术生态，但这不等于 PostGIS 本身是国产数据库。

原理：PostgreSQL、PostGIS和国产数据库的技术关系

1. PostgreSQL是什么

PostgreSQL 是一个开源关系型数据库管理系统，支持标准 SQL、事务、索引、视图、触发器、扩展机制等能力。它本身是通用数据库，不是专门的 GIS 软件。

PostgreSQL 的一个重要特点是扩展能力强。PostGIS 正是利用了 PostgreSQL 的扩展机制，把空间数据管理能力加入到数据库中。

2. PostGIS是什么

PostGIS 是 PostgreSQL 的空间扩展。安装 PostGIS 后，可以在数据库中使用 geometry、geography、raster 等空间相关能力，并调用大量空间函数。

GIS 工程中常见的 PostGIS 能力包括：

  • 存储点、线、面、多部件几何对象；
  • 使用 GiST、SP-GiST、BRIN 等索引提升空间查询性能；
  • 执行 ST_Intersects、ST_Within、ST_Contains、ST_Distance 等空间关系判断；
  • 进行缓冲区、裁剪、相交、合并、简化等空间处理；
  • 管理 SRID，也就是空间参考标识，用于表达坐标系；
  • 与 QGIS、GeoServer、GDAL、Python GeoPandas 等工具集成。

3. 国产数据库和PostGIS是什么关系

国产数据库是数据库产品的产业归属概念，而 PostGIS 是开源空间扩展的技术组件。二者不是同一维度。

在实际项目中，它们可能出现三种关系：

场景 典型描述 GIS关注点
直接使用 PostgreSQL/PostGIS 使用开源 PostgreSQL 数据库并安装 PostGIS 扩展 空间函数完整、生态成熟，但需自行评估运维和合规要求
使用兼容 PostgreSQL 的国产数据库 数据库产品由国内厂商提供，并声明兼容 PostgreSQL 语法或协议 重点验证 PostGIS 函数、空间索引、GIS工具连接兼容性
使用国产数据库自带空间能力 数据库提供自己的空间类型、空间索引和空间函数 重点验证 OGC 标准兼容、函数差异、迁移成本和性能

所以，判断一个国产化数据库方案能否承载 GIS 数据治理，不能只看“兼容 PostgreSQL”四个字，而要逐项验证空间能力。

步骤：GIS项目中如何评估PostGIS与国产化替代方案

步骤一：先明确你的GIS数据类型

数据库选型前，先把数据类型列清楚。不同 GIS 数据对数据库能力要求差异很大。

  • 地块、行政区、管线、道路：以矢量面、线数据为主，适合重点评估 geometry 类型和空间索引。
  • 网格、POI、轨迹点：点数据量可能很大，要关注批量写入、分区表和索引性能。
  • 遥感影像、倾斜摄影、三维瓦片：通常不建议直接全部塞进关系数据库，应结合对象存储、文件服务或瓦片服务。
  • 时空轨迹、车辆定位、传感器数据：除空间查询外，还要评估时间字段索引、分区策略和冷热数据归档。
  • 权属、审批、巡查业务数据：要关注事务一致性、权限控制、审计和业务表关联。

如果项目主要是矢量空间数据治理，PostGIS 通常是非常值得评估的方案。如果项目核心是海量影像管理或三维场景调度，则不能只依赖 PostGIS，需要设计对象存储、瓦片服务和元数据库协同架构。

步骤二：检查GIS软件连接能力

空间数据库不是孤立使用的，必须看它能否被现有 GIS 工具稳定访问。建议至少验证以下工具链：

  • QGIS 是否可以连接、浏览图层、编辑要素、保存样式；
  • GeoServer 是否可以发布 PostGIS 图层为 WMS、WFS、WMTS 或矢量瓦片服务；
  • GDAL/OGR 是否可以正常读取和写入；
  • Python GeoPandas、SQLAlchemy、psycopg 是否可以访问空间表；
  • ArcGIS Pro 是否可以通过支持的数据库连接方式读取业务所需数据；
  • WebGIS 后端接口是否可以执行分页、过滤、空间查询和权限控制。

很多国产化替代问题不是“数据库连不上”，而是“普通表能连，空间字段不兼容”“能查询，不能编辑”“能发布，空间过滤性能差”。这些问题必须在测试阶段暴露。

步骤三：验证PostGIS核心函数兼容性

如果你评估的是 PostgreSQL/PostGIS，重点是部署、性能和数据模型设计。如果你评估的是 PostgreSQL 兼容国产数据库，则要重点检查 PostGIS 函数是否真正可用。

建议准备一组最小测试 SQL：

CREATE EXTENSION IF NOT EXISTS postgis;

SELECT postgis_full_version();

CREATE TABLE gis_test (
    id serial PRIMARY KEY,
    name text,
    geom geometry(Polygon, 4490)
);

CREATE INDEX gis_test_geom_idx
ON gis_test
USING GIST (geom);

SELECT ST_Area(geom), ST_AsText(ST_Centroid(geom))
FROM gis_test;

SELECT a.id, b.id
FROM gis_test a
JOIN gis_test b
ON ST_Intersects(a.geom, b.geom);

这组 SQL 可以初步检查扩展安装、空间类型、SRID、空间索引、几何计算和空间关系查询。如果这些基础能力都不稳定，就不适合作为 GIS 数据治理底座。

步骤四：验证坐标系和SRID管理

GIS 数据治理中，坐标系错误比数据库品牌问题更常见。PostGIS 使用 SRID 标识空间参考，例如 EPSG:4326、CGCS2000 相关坐标系等。

需要区分两个函数：

  • ST_SetSRID：给几何对象设置 SRID 标签，不改变坐标数值；
  • ST_Transform：进行坐标转换，会改变坐标数值。

很多“PostGIS面积不准”“空间叠加错位”“WebGIS图层偏移”的问题，本质上不是 PostGIS 不行，而是数据 SRID 错了、经纬度和投影坐标混用了，或者前端地图底图坐标系没有统一。

步骤五：做一套真实数据迁移测试

不要只用几十条测试数据判断数据库方案。建议用真实项目数据做一轮迁移验证：

  1. 从 Shapefile、GeoPackage、FileGDB、Oracle Spatial 或 SQL Server 导出样本数据；
  2. 使用 ogr2ogr、QGIS 数据库管理器或 ETL 工具导入目标数据库；
  3. 检查字段类型、中文编码、字段长度、空几何、无效几何；
  4. 创建空间索引和业务字段索引；
  5. 执行典型空间查询、属性查询和分页查询；
  6. 用 QGIS 或 GeoServer 读取并发布；
  7. 记录不兼容函数、性能瓶颈和数据修复规则。

迁移测试的目标不是证明某个方案“能跑”，而是找出在生产环境中会出问题的点。

常见坑：PostGIS国产化替代项目里最容易踩的坑

坑一：把PostGIS写成国产数据库产品

这是方案文档中最常见的表述错误。PostGIS 是空间扩展，不是数据库产品，更不是国产数据库。正确写法应根据实际方案区分：

  • 开源方案：PostgreSQL + PostGIS 空间数据库；
  • 国产化方案：某国产数据库 + 空间扩展能力；
  • 兼容方案：兼容 PostgreSQL/PostGIS 生态的国产数据库。

坑二：只测普通SQL，不测空间SQL

很多数据库兼容性测试只执行普通增删改查，这对 GIS 项目远远不够。空间数据库必须测试 ST_Intersects、ST_Within、ST_DWithin、ST_Buffer、ST_Union、ST_IsValid、ST_Transform 等函数。

坑三：没有为空间字段建立索引

PostGIS 空间查询慢，很多时候是因为没有创建空间索引，或者 SQL 写法导致索引没有被有效使用。常见索引写法如下：

CREATE INDEX idx_parcel_geom
ON parcel
USING GIST (geom);

建立索引后，应使用执行计划检查查询是否走索引：

EXPLAIN ANALYZE
SELECT *
FROM parcel
WHERE ST_Intersects(
    geom,
    ST_GeomFromText('POLYGON((...))', 4490)
);

坑四：把所有GIS数据都放进数据库

PostGIS 很适合管理矢量空间数据和空间关系，但不意味着所有 GIS 数据都应该直接入库。影像原始文件、三维瓦片、切片缓存、海量附件通常更适合放在文件系统、对象存储或专门的数据服务中，数据库保存索引、元数据和权限关系即可。

坑五：忽略无效几何

空间叠加失败、面积计算异常、缓冲区报错，经常来自无效几何。例如自相交面、重复节点、环方向混乱、空几何等。PostGIS 中可以先检查：

SELECT id, ST_IsValid(geom), ST_IsValidReason(geom)
FROM parcel
WHERE NOT ST_IsValid(geom);

必要时可以使用 ST_MakeValid 修复，但修复后要人工抽查，因为几何结构可能发生变化。

方法比较：PostGIS、商业空间数据库与国产数据库怎么选

方案 优势 限制 适合场景
PostgreSQL/PostGIS 开源生态成熟，GIS工具支持广，空间函数丰富 需要团队具备数据库运维、备份、调优和安全管理能力 WebGIS平台、空间数据治理、矢量数据管理、开源GIS体系
商业空间数据库 企业级能力完善，厂商支持体系成熟，适合复杂组织环境 授权成本较高，生态绑定较强 大型政企系统、既有商业GIS体系、强服务保障项目
国产数据库自带空间能力 满足国产化采购和信创环境要求，厂商本地支持较强 空间函数、GIS工具兼容性和生态成熟度需要实测 国产化替代、政务内网、信创平台适配
兼容PostgreSQL的国产数据库 迁移 PostgreSQL 业务相对友好，可能复用部分SQL和应用代码 PostGIS兼容程度不能只看宣传，需要逐项验证 已有PostgreSQL/PostGIS系统迁移、国产化改造项目

如果你的核心目标是快速构建稳定的空间数据治理能力，PostGIS 是一个非常强的技术基线。如果项目有明确国产化要求，则应在国产数据库候选产品中重点验证 PostGIS 兼容性、空间函数覆盖度、GIS 软件连接能力和生产性能。

检查清单：评估PostGIS与国产数据库空间能力时看什么

下面这份清单适合用于项目调研、招标技术参数、POC 测试和验收前自查。

  • 数据库归属是否清楚：明确是 PostgreSQL/PostGIS、国产数据库自带空间能力，还是兼容 PostgreSQL 的国产数据库。
  • 空间类型是否支持：检查 Point、LineString、Polygon、MultiPolygon、GeometryCollection 等类型。
  • SRID是否可靠：检查坐标系定义、ST_SetSRID、ST_Transform、空间参考表是否可用。
  • 空间索引是否可用：验证 GiST 或等效空间索引创建、查询计划和性能表现。
  • 核心函数是否覆盖：至少测试 ST_Intersects、ST_Within、ST_Contains、ST_DWithin、ST_Buffer、ST_Union、ST_Area、ST_Length。
  • 无效几何能否处理：测试 ST_IsValid、ST_IsValidReason、ST_MakeValid 等能力。
  • GIS工具是否适配：测试 QGIS、GeoServer、GDAL、Python、ArcGIS Pro 等实际工具链。
  • 数据迁移是否顺畅：验证 Shapefile、GeoPackage、FileGDB、Oracle Spatial 等来源数据迁移。
  • 权限和审计是否满足要求：检查角色、模式、表权限、行级权限、日志审计和备份策略。
  • 性能是否用真实数据验证：不要只用空库和小样本测试，要用真实空间范围、真实字段和真实并发场景。

FAQ：PostGIS是国产数据库相关常见问题

1. PostGIS是国产数据库吗？

不是。PostGIS 是 PostgreSQL 的开源空间扩展，不是数据库产品，也不是国产数据库。它提供 GIS 空间数据存储、空间索引和空间分析函数。

2. PostgreSQL是国产数据库吗？

PostgreSQL 是国际开源数据库项目，不属于国产数据库产品。但国内有不少数据库产品兼容 PostgreSQL 协议、语法或生态，具体兼容程度需要以产品文档和实测结果为准。

3. 国产数据库能直接使用PostGIS吗？

不一定。即使某国产数据库声明兼容 PostgreSQL，也不代表完整支持 PostGIS。GIS 项目必须实测扩展安装、空间字段、空间索引、空间函数和工具连接能力。

4. PostGIS适合做GIS数据治理吗？

适合，尤其适合矢量空间数据治理、空间查询、空间叠加、空间关系判断、WebGIS 后端数据服务等场景。但对于海量影像、三维瓦片和大规模实时轨迹，应结合对象存储、消息队列、时序数据库或专门的数据服务架构。

5. PostGIS和GeoServer是什么关系？

PostGIS 负责存储和查询空间数据，GeoServer 负责把空间数据发布成地图服务。常见架构是 PostGIS 存数据，GeoServer 发布 WMS、WFS、WMTS 等服务，前端再用 OpenLayers、Leaflet 或 Cesium 加载。

6. 做国产化替代时，PostGIS系统迁移最该注意什么？

最该注意空间函数兼容、空间索引、坐标系、无效几何、GIS工具连接和性能测试。不要只迁移表结构和普通属性字段，空间字段才是 GIS 系统迁移的关键。

结论：不要把PostGIS当成国产数据库，要把它当成空间能力基线

回到开头的问题：PostGIS是国产数据库吗？答案是否定的。PostGIS 是 PostgreSQL 的空间扩展，不是国产数据库产品。

但从 GIS 工程实践看，PostGIS 仍然非常重要。它提供了一套成熟、开放、广泛使用的空间数据库能力，可以作为评估国产数据库空间能力、设计 GIS 数据治理架构、迁移传统空间数据库系统的重要参照。

如果你的项目没有强制国产化要求，PostgreSQL/PostGIS 是值得认真考虑的空间数据库方案。如果项目有国产化替代要求，就不要只看“兼容 PostgreSQL”的宣传语，而要用真实 GIS 数据、真实空间 SQL、真实工具链做验证。

一句话总结：PostGIS不是国产数据库，但它是理解空间数据库能力和评估国产化GIS替代方案的重要技术坐标。