自从 GIS 软件开发以来，ShapeFile等格式被广泛用于存储空间数据，但这些文件格式文件需要特殊的软件才能读取和写入，并发用户可能会导致数据损坏和速度变慢，并且复杂的问题需要复杂的软件来处理。 因此，对多用户的支持、复杂的临时查询以及在大型数据集上的高性能是使空间数据库与基于文件的系统有所区别的关键因素。

2001 年 5 月，Refractions Research 发布了 PostGIS 的第一版。PostGIS 0.1 拥有对象、索引和一些趁手的函数。那时，它只是适合存储数据和检索数据，并不适合分析数据。随着函数数量的增加，对组织原则的需求变得明显。开放地理空间联盟（Open Geospatial Consortium）的"Simple Features for SQL"（简称 SFSQL）规范提供了参考，其中包括函数命名和要求的指南。

随着PostGIS对简单分析和空间连接的支持，Mapserver 成为第一个外部应用程序，为数据库中的数据提供可视化展示。

在接下来的几年里，PostGIS功能的数量不断增长，但其功能仍然有限。许多最有趣的函数，例如ST_Intersects（）、ST_Buffer（）、ST_Union（）都很难编码，从头开始编写它们开展了多年的工作。

幸运的是，第二个项目——“Geometry Engine, Open Source” 或 GEOS，也随之出现。GEOS库提供了实现 SFSQL 规范所需的算法。通过引入GEOS，PostGIS在版本0.8中为 SFSQL 提供了完整的支持。

随着PostGIS数据容量的增长，出现了另一个问题：用于存储几何信息的表示方式相对低效。对于小型对象，如点和线，公示中的元数据可能会有高达300%的额外开销。出于性能原因，有必要对表示进行精简。通过缩小元数据头和所需的维度，额外开销大大减少。在PostGIS 1.0中，这种新的、更快速、轻量级的表示方式成为了默认选项。

最新版本的 PostGIS 继续添加功能和性能改进，以及对 PostgreSQL 核心系统中新功能的支持。

那么为什么当时选用 PostgreSQL，不在 MySQL 上构建 PostGIS呢？这是因为PostgreSQL提供了一种非常简单的开发路径来添加新的空间类型，其具有如下特点：

• 默认具备经过验证的可靠性和事务完整性（ACID）
• 对 SQL 标准的精心支持（完整的 SQL92）
• 插拔式扩展和功能扩展
• 以社区为导向的发展模式
• 对列大小（“TOAST”支持元组）没有限制，以支持大型 GIS 对象
• 通用索引结构 （GiST） 允许 R 树索引
• 易于添加自定义功能