我已经使用了所有三个数据库并在它们之间进行了迁移，所以希望我仍然可以在旧帖子中添加一些内容。十年前，我的任务是把一个庞大的——4.5 亿个空间对象——数据集从 GML 放到一个空间数据库中。我决定尝试 MySQL 和 Postgis，当时 SQL Server 没有空间，而且我们的启动氛围很小，所以 MySQL 看起来很合适。随后我参与了 MySQL，我参加了几次会议/发言，并积极参与了 MySQL 中更符合 GIS 的功能的 beta 测试，最终在 5.5 版中发布。随后，我参与了将我们的空间数据迁移到 Postgis 并将我们的公司数据（带有空间元素）迁移到 SQL Server 的工作。这些是我的发现。
MySQL
1）。稳定性问题。在 5 年的时间里，我们遇到了几个数据库损坏问题，这些问题只能通过在索引文件上运行 myismachk 来解决，这个过程在 4.5 亿行表上可能需要超过 24 小时。
2）。直到最近，只有 MyISAM 表支持空间数据类型。这意味着，如果您想要交易支持，那么您就不走运了。InnoDB 表类型现在确实支持空间类型，但不支持它们的索引，考虑到空间数据集的典型大小，这并不是非常有用。请参阅http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html我参加会议的经验是，空间在很大程度上是事后才想到的——我们已经实现了复制、分区等，但它不适用于空间。编辑：在即将发布的 5.7.5 版本中，InnoDB 将最终支持空间列索引，这意味着 ACID、外键和空间索引最终将在同一引擎中可用。
3）。与 Postgis 和 SQL Server 空间相比，空间功能极为有限。仍然没有 ST_Union 函数作用于整个几何字段，这是我最常运行的查询之一，即您不能编写：
select attribute, ST_Union(geom) from some_table group by some_attribute
这在 GIS 环境中非常有用。Select ST_Union(geom1, const_geom) from some_table，即其中一个几何图形是硬编码的常数几何图形相比之下有点限制。
4）。不支持栅格。能够在数据库中进行组合矢量栅格分析是非常有用的 GIS 功能。
5）。不支持从一个空间参考系统到另一个空间参考系统的转换。
6）。自从被甲骨文收购后，空间真的被搁置了。
总的来说，为了公平起见，MySQL 多年来一直支持我们的网站、WMS 和一般空间处理，并且易于设置。不利的一面是，数据损坏是一个问题，并且由于被迫使用 MyISAM 表，您放弃了 RDBMS 的许多好处。
邮政地理信息系统
考虑到我们在使用 MySQL 时遇到的问题，我们最终转换为 Postgis。这次经历的关键点是。
1）。极端的稳定性。5 年内没有数据损坏，现在我们在 centos 虚拟机上拥有大约 25 个 Postgres/GIS 盒子，处于不同程度的负载下。
2）。快速发展——光栅、拓扑、3D 支持是最近的例子。
3）。非常活跃的社区。Postgis irc 频道和邮件列表是极好的资源。Postgis 参考手册也很出色。http://postgis.net/docs/manual-2.0/
4）。与 OSGeo 旗下的其他应用程序（例如 GeoServer 和 GDAL）配合得非常好。
5）。存储过程可以用多种语言编写，除了默认的 plpgsql，例如 Python 或 R。
5）。Postgres 是一个非常符合标准、功能齐全的 RDBMS，旨在保持接近 ANSI 标准。
6）。支持窗口函数和递归查询——不是在 MySQL 中，而是在 SQL Server 中。这使得编写更复杂的空间查询更加简洁。
SQL 服务器。
我只使用了 SQL Server 2008 空间功能，该版本的许多烦恼——缺乏对从一个 CRS 转换到另一个 CRS 的支持，需要将您自己的参数添加到空间索引——现在已经得到解决。
1）。由于 SQL Server 中的空间对象基本上是 CLR 对象，因此语法感觉是倒退的。您编写的不是 ST_Area(geom)，而是 geom.STArea()，当您将函数链接在一起时，这一点变得更加明显。在函数名中去掉下划线只是一个小麻烦。
2）。我有许多已被 SQL Server 接受的无效多边形，缺少 ST_MakeValid 函数会使这有点痛苦。
3）。仅限窗户。通常，Microsoft 产品（如 ESRI 产品）旨在很好地相互配合，但并不总是将标准的合规性和互操作性作为主要目标。如果您经营的是一家只有窗户的商店，这不是问题。
更新：在 SQL Server 2012 上玩了一下，我可以说它已经有了很大的改进。现在有一个很好的几何验证功能，对 Geography 数据类型有很好的支持，包括一个 FULL GLOBE 对象，它允许表示占据多个半球的对象，并支持复合曲线和圆形字符串，这对精确和紧凑很有用除其他外，弧（和圆）的表示。将坐标从一个 CRS 转换到另一个 CRS 仍然需要在 3rd 方库中完成，尽管这在大多数应用程序中并不是一个阻碍。
我还没有使用具有足够大数据集的 SQL Server 来与 Postgis/MySQL 进行一对一的比较，但是从我所看到的功能表现正确，虽然不像 Postgis 那样功能齐全，但它是对 MySQL 产品的巨大改进.
很抱歉这么长的回答，我希望我多年来所遭受的一些痛苦和快乐可能对某人有所帮助。