从Oracle迁移到PostgreSQL的十大理由

来源：这里教程网时间：2026-03-14 19:59:32 作者：

作者：保罗·纳穆格 Paul Namuag 能够担任各种职务，受益于在过去的 18 年中有机会使用各种技术。他从 2005 年开始担任图形艺术家和 MS .Net 开发人员，并转而使用开源技术，并且是使用 LAMP stack 的 Web 开发人员。之后，他是一名软件工程师 / 游戏工程师，曾与多家公司合作开发移动或桌面和 Web 应用程序。 2013 年下半年，他转任 MySQL 支持工程师，然后成为 Percona 的远程 DBA ，从而有机会了解大数据，高可伸缩性，高可用性应用程序的工作方式。

前言

Oracle 关系数据库管理系统（ RDBMS ）已被企业广泛使用，迄今为止被认为是市场上最先进的数据库技术。通常，它是 RDBMS 中最常拿来与其他数据库进行比较的的产品，充当了产品应提供的标准“事实”。 db-engines.com 将其评为当今市场上排名第一的 RDBMS 。 PostgreSQL 被列为第四名 RDBMS ，但这并不意味着迁移到 PostgreSQL 没有任何优势。 PostgreSQL 自 1989 年以来一直存在，并于 1996 年开放源代码。 PostgreSQL 从 2017 年和 2018 年连续两年获得年度 DBMS 奖。这表明它从没有停止吸引大量用户和企业的青睐。 PostgreSQL 之所以引起广泛关注的原因之一是因为人们正在寻找 Oracle 的替代产品，以便他们可以削减组织的高成本并避免供应商的锁定。从工作高效的Oracle 数据库迁移可能是一项艰巨的任务。诸如公司的 TCO （总拥有成本）之类的担忧是公司拖延决定是否放弃甲骨文的原因之一。在此博客中，我们将介绍一些公司选择离开Oracle 并迁移到 PostgreSQL 的主要原因。

原因一：这是一个真正的开源项目

PostgreSQL 是开源的，并根据 PostgreSQL 许可证发行， PostgreSQL 许可证是自由的开源许可证，类似于 BSD 或 MIT 许可证。获得产品和支持不需要任何费用。如果要使用数据库软件，则意味着您可以免费获得PostgreSQL 数据库的所有可用功能。 PostgreSQL 在数据库领域已有 30 多年的悠久历史，自 1996 年以来就一直以开源为基础。数十年来，开发人员一直致力于创建扩展功能。这本身就能促使开发人员，机构和组织选择 PostgreSQL 用于企业应用程序，支持领先的业务和移动应用程序。企业再次意识到，像Postgres 这样的开源数据库解决方案提供了更大的容量，灵活性和支持，而并不完全依赖于任何一家公司或开发人员。与以前的 Linux 一样， Postgres 由致力于解决日常业务问题，并选择将解决方案返回给社区的用户设计（并将继续保持）。与像 Oracle 这样的大型开发商不同，后者可能有不同的动机来开发有利可图的产品或支持狭窄但有利润的市场，而 Postgres 社区致力于为用户日常使用关系数据库开发最好的工具。 PostgreSQL 通常执行这些任务而不会增加太多复杂性。其设计严格专注于处理数据库，而不必浪费资源，例如通过添加功能来管理其他 IT 环境。这是该开源软件的使用者从 Oracle 迁移到 PostgreSQL 时的事情之一。花大量时间研究有关 Oracle 数据库如何运行或如何优化和调优的复杂技术，最终可能会得到其昂贵的支持。这吸引了机构或组织寻找替代方案，可以减轻成本的同时，带来利润和生产率。请查看我们以前的博客，了解 PostgreSQL 在 SQL 语法和 Oracle 语法之间的匹配能力。

原因二：没有许可限制，而且社区很大

对于Oracle RDBMS 平台的用户来说，很难找到任何类型的免费或不收取高额费用的社区支持。机构，组织和开发人员通常能在网上找到替代信息，这些信息可以免费提供问题的答案或解决方案。使用Oracle 时，很难确定是否选择产品技术支持，因为，通常涉及较多费用。使用 PostgreSQL ，该社区是免费的，并且有很多拥有丰富经验的专家，他们乐于为您解决当前的问题。您可以在这里 https://lists.postgresql.org/ 订阅邮件列表，以开始与社区联系。接触 PostgreSQL 的新手或天才可在这里进行交流，展示和共享解决方案、技术、错误、新发现，甚至共享其新兴软件。您甚至可以使用 irc.freenode.net 并加入 #postgresql 频道，从 IRC 聊天中寻求帮助。您还可以加入 https://postgres-slack.herokuapp.com/ 或 https://postgresteam.slack.com/ 通过 Slack 与社区联系。有很多选择，很多开源组织可以为您提供帮助。有关从何处开始的更多详细信息，请访问 https://www.postgresql.org/community/ 。如果您愿意为PostgreSQL 中更优质的专业服务买单，这里也有很多选择。即使在网站 https://www.postgresql.org/support/professional_support/northamerica/ 上查看，也可以找到大量公司，其中一些公司的价格便宜。即使在 Severalnines ，我们也提供对 Postgres 的支持，它是 ClusterControl 许可或 DBA 技术咨询的一部分。

原因三：广泛支持SQL一致性

PostgreSQL 一直热衷于适应和遵循 SQL 语言标准。 SQL 标准的正式名称是 ISO / IEC 9075 “数据库语言 SQL ”。标准发行版的任何后续修订版本都将替换以前的版本，因此声称与早期版本保持一致并没有多少价值。与Oracle 不同，仍然存在一些不符合 ANSI 标准 SQL （结构化查询语言）的关键字或运算符。例如，初学者容易混淆的 OUTER JOIN （ + ）（ Oracle 运算符语法）。 PostgreSQL 遵循用于 JOIN 语法的 ANSI-SQL 标准，并具有与其他开源 RDBMS 数据库（例如 MySQL / Percona / MariaDB 数据库）轻松跳转的优势。在Oracle 中非常常见的另一种语法是使用分层查询。 Oracle 使用非标准的 START WITH..CONNECT BY 语法，而在 SQL:1999 中，层次结构查询是通过递归通用表表达式 (CTE) 实现的。例如，对比以下分层查询的不同表达： Oracle SELECT restaurant_name, city_name FROM restaurants rs START WITHrs.city_name = 'TOKYO' CONNECT BY PRIOR rs.restaurant_name = rs.city_name; PostgreSQL WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name FROM restaurants WHERE city_name = 'TOKYO' UNION SELECT m.restaurant_name, m.city_name FROM restaurants m JOIN tmp ON tmp.restaurant_name = m.city_name) SELECT restaurant_name, city_name FROM tmp; PostgreSQL 与其他顶级开源 RDBMS （例如 MySQL / MariaDB ）具有非常相似的方法。根据PostgreSQL 手册， PostgreSQL 开发的目的是与标准的最新正式版本保持一致，在这种情况下，这种一致不与传统功能或常识相矛盾。支持 SQL 标准所需的许多功能，尽管有时语法或功能略有不同。实际上，这对于 PostgreSQL 来说是很棒的，因为无论怎样， PostgreSQL 都受到不同组织的支持和协作。关键在于其 SQL 语言符合标准的要求。 PostgreSQL 的开发旨在与标准的最新正式版本保持一致，在这种情况下，这种一致性不会与传统功能或常识相抵触。支持 SQL 标准所需的许多功能，尽管有时语法或功能略有不同。随着时间的流逝，有望进一步实现一致性。

原因四：查询并行

公平地说，与Oracle 的 SQL 语句并行执行相比， PostgreSQL 的查询并行性并不丰富。 Oracle 并行性的功能包括带提示的语句排队，设置并行度（ DOP ），设置并行度策略或自适应并行性的能力。 PostgreSQL 根据支持的计划具有简单的并行度，但这并没有定义 Oracle 在开源 PostgreSQL 方面的优势。 PostgreSQL 的并行性一直在不断提高，并被社区不断增强。当 PostgreSQL 10 发布时，它增强了对公众的吸引力，特别是对合并连接，位图堆扫描，索引扫描和仅索引扫描，聚集合并等并行性支持的改进。还为 pg_stat_activity 添加了统计信息。在PostgreSQL V10 中，默认情况下禁用并行性，您需要设置变量 max_parallel_workers_per_gather postgres=# \timing Timing is on. postgres=# explain analyze select * from imdb.movies wherebirthyear >= 1980 and birthyear <=2005; QUERYPLAN ---------------------------------------------------------------------------------------------------------------- Seq Scan on movies (cost=0.00..215677.28rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1) Filter: ((birthyear >= 1980) AND (birthyear <=2005)) Rows Removed by Filter: 8241546 Planning time: 0.039 ms Execution time: 525.195 ms (5 rows) Time: 525.582 ms postgres=# \o /dev/null postgres=# select * from imdb.movies where birthyear>= 1980 and birthyear <=2005; Time: 596.947 ms 查询计划显示，它的实际时间大约可以是522.5 ms ，然后实际查询执行时间大约是 596.95 ms 。来看启用并行性后的结果： postgres=# set max_parallel_workers_per_gather=2; Time: 0.247 ms postgres=# explain analyze select * from imdb.movies wherebirthyear >= 1980 and birthyear <=2005; QUERYPLAN ------------------------------------------------------------------------------------------------------------------------------- Gather (cost=1000.00..147987.62 rows=41630width=68) (actual time=0.172..339.258 rows=84473 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on movies (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3) Filter: ((birthyear >= 1980) AND (birthyear <=2005)) Rows Removed by Filter: 2747182 Planning time: 0.096 ms Execution time: 342.735 ms (8 rows) Time: 343.142 ms postgres=# \o /dev/null postgres=# select * from imdb.movies where birthyear>= 1980 and birthyear <=2005; Time: 346.020 ms 查询计划确定查询需要使用并行性，然后使用Gather 节点。它的实际时间估计为 339 毫秒（包含 2 个并行工作进程），估计为 264 毫秒（查询计划汇总之前）。现在，查询的实际执行时间为 346ms ，非常接近查询计划中估计的实际时间。这仅说明了PostgreSQL 的性能和益处。尽管 PostgreSQL 在使用并行性或查询计划确定它比使用并行性要快时有其自身的局限性，但它的功能并没有与 Oracle 产生巨大差异。 PostgreSQL 的并行性很灵活，只要您的查询与查询并行性所需的顺序匹配，就可以正确启用或利用它。

原因五：先进的JSON支持，并且不断在提升

与其他开放源代码RDBMS 相比， PostgreSQL 中的 JSON 支持始终处于同等水平。可以看一下 LiveJournal 的博客（博客地址https://obartunov.livejournal.com/200076.html ），其中PostgreSQL 的 JSON 支持显示出相比其他 RDBMS 总是更高级。 PostgreSQL 具有大量的 JSON 函数和功能。 JSON 数据类型在 PostgreSQL-9.2 中引入。从那时起，它有了许多重大的提升，并且在 PostgreSQL-9.4 中出现了主要的提升，增加了 JSONB 的数据类型。 PostgreSQL 提供了两种存储 JSON 数据的数据类型： json 和 JSONB 。对于 JSONB ，它是 JSON 数据类型的高级版本，以二进制格式存储 JSON 数据。这是主要的增强功能，与在 PostgreSQL 中搜索和处理 JSON 数据的方式有很大的不同。 Oracle 也广泛支持 JSON 。相比之下， PostgreSQL 提供了广泛的支持，可以用于数据检索、数据格式化或条件操作，这些操作会影响数据的输出，甚至影响数据库中存储的数据。使用 jsonb 数据类型存储的数据具有很大的优势，即能够使用 GIN （通用倒排索引）， GIN 可用于有效搜索大量 jsonb 文档中出现的键或键 / 值对。 PostgreSQL 有额外的扩展，有助于将 jsonb 的类型转换为它支持的过程语言。这些扩展是针对 PL/Perl 的 jsonb_plperl 和 jsonb_plperlu 。而对于 PL/Python ，它们是 jsonb_plpythonu 、 jsonb_plpython2u 和 jsonb_plpython3u 。例如，使用 jsonb 值来映射 Perl 数组，您可以使用 jsonb_plperl 或 jsonb_plperlu 扩展。 ArangoDB 发布了一个基准，将 PostgreSQL 的 JSON 性能与其他支持 JSON 的数据库进行了比较。尽管这是一个较老的博客，但它仍然展示了 PostgreSQL 的 JSON 与其他数据库相比的性能。在其他数据库中， JSON 是其内核的核心功能。这说明 JSON 即使只是 PostgreSQL 的附加功能也具有一定的优势。

原因六：主要云供应商对DBaaS的支持

PostgreSQL 已作为 DBaaS 得到广泛支持。这些服务来自亚马逊、微软 Azure 数据库和谷歌 Cloud SQL 。相比之下，Oracle 仅在 Amazon RDS for Oracle 上可用。主要参与者提供的服务以实惠的价格开始，并且可以根据您的需求进行灵活设置。这有助于机构和组织进行相应的设置，并减轻 Oracle 平台上捆绑的巨额成本。

原因七：更好地处理海量数据

PostgreSQL RDBMS 不适用于处理分析和数据仓库类的工作负载。 PostgreSQL 是一个面向行的数据库，但是它具有存储大量数据的能力。 PostgreSQL 在处理数据存储时有以下限制：

限制	值
最大数据库大小	无限
最大表尺寸	32TB
最大行大小	1.6TB
最大字段大小	1GB
每个表的最大行数	无限
每个表的最大列数	250-1600 ，取决于列类型
每张表的最大索引	无限

PostgreSQL 的主要优点是，已经有一些插件可以合并以处理大数据量。 TimeScaleDB 和 CitusData 的 cstore_fdw 可以合并到时间序列数据库，存储移动、物联网应用程序中的大量数据，作为数据分析或数据仓库的插件之一。实际上， ClusterControl （某产品）提供了对 TimeScaleDB 的支持，该支持既简单又易于部署。如果要使用PostgreSQL 的核心功能，则可以使用 jsonb 存储大量数据。例如，大量文档（ PDF ， Word ，电子表格）可以使用 jsonb 数据类型存储。对于地理定位应用程序或系统，可以使用 PostGIS 。

原因八：廉价的可伸缩性，高可用性，冗余/地理冗余和容错解决方案

Oracle 提供了类似的解决方案，例如 OracleGrid ， Oracle Real Application Clusters （ RAC ）， Oracle Clusterware 和 Oracle Data Guard 。这些技术可能会增加您的成本，并且部署和稳定维护的费用出乎意料地昂贵，而且一旦用上很难放弃这些解决方案。必须培训技术人员增强技能，并培养参与部署和实施过程的人员。 PostgreSQL 有大量的支持，并且有很多选择。 PostgreSQL 包含内置核心程序包中的流和逻辑复制。您还可以为 PostgreSQL 设置同步复制，以拥有更多的高可用群集，同时使备用节点处理读取查询。对于高可用性，我们建议您阅读我们的博客 PostgreSQL 顶级 PG 集群高可用性（ HA ）解决方案，其中涵盖了许多不错的工具和技术供您选择。还有一些企业功能可以提供高可用性，监视和备份解决方案。ClusterControl 是这项技术之一，与 Oracle 解决方案相比，价格合理。

原因九：支持多种过程语言：PL/pgSQL、PL/Tcl、PL/Perl 和 PL/Python

从9.4 版开始， PostgreSQL 具有一个很棒的功能，您可以根据自己的选择定义新的过程语言。尽管不支持所有编程语言，但是它具有许多受支持的语言。当前，通过基本发行版，它包括 PL / pgSQL ， PL / Tcl ， PL/ Perl 和 PL / Python 。外部语言是：

名称	语言	网站
PL/Java	Java	https://tada.github.io/pljava/
PL/Lua	Lua	https://github.com/pllua/pllua
PL/R	R	https://github.com/postgres-plr/plr
PL/ sh	Unix shell	https://github.com/petere/plsh
PL/ v8	JavaScript	https://github.com/plv8/plv8

这样做的好处是，与Oracle 不同，新进入 PostgreSQL 的开发人员可以快速为他们的应用程序系统提供业务逻辑，而无需花费更多时间来学习 PL / SQL 。 PostgreSQL 使开发人员的环境更加轻松和高效。 PostgreSQL 的这种性质有助于开发人员喜欢 PostgreSQL 并开始将企业平台解决方案转移到开源环境。

原因十：大数据集、文本数据的灵活索引（GIN，GiST，SP-GiST和BRIN）

PostgreSQL 在支持索引方面具有巨大的优势，这有利于处理大数据。 Oracle 有很多索引类型，它们也有利于处理大型数据集，尤其是全文索引。但是对于 PostgreSQL ，这些类型的索引是根据你的目的而灵活设置的。例如，这些类型的索引适用于大数据 :

GIN-（广义倒排索引）

此类索引适用于jsonb ， hstore ， range 和 arrays 数据类型列。当您的数据类型在单个列中包含多个值时，此功能很有用。根据 PostgreSQL 文档，“ GIN 用于处理要建立索引的项目是复合值的情况，并且要通过索引处理的查询搜索出现在复合项目内的元素值。例如，这些项目可以是文档，而查询可以是对包含特定单词的文档的搜索。”

GiST-（通用搜索树）

由节点页面组成的高度平衡的搜索树。节点由索引行组成。通常，叶节点的每一行（叶行）都包含一些谓词（布尔表达式）和对表行（TID ）的引用。 GiST 索引最好用于几何数据类型，比如查看两个多边形是否包含某个点。在一种情况下，一个特定的点可能包含在一个框中，而另一个点只存在于一个多边形中。在处理全文搜索时，要利用 GiST 索引的最常见数据类型是几何类型和文本在选择使用哪种索引类型（GiST 或 GIN ）时，请考虑以下性能差异：

l GIN 索引查找速度比 GiST 快三倍

l GIN 索引的构建时间比 GiST 长三倍

l GIN 索引的更新速度稍慢于 GiST 索引，但是如果禁用了快速更新支持，则大约慢 10 倍

l GIN 索引比 GiST 索引大 2 至 3 倍根据经验，GIN 索引最适合静态数据，因为查找速度更快。对于动态数据， GiST 索引的更新速度更快。

SP-GiST-（空间分区GiST）

对于具有自然但不均匀集群的较大数据集。这种类型的索引利用空间分区树。当您的数据有一个自然的集群元素，并且不是一个均衡的树时，SP-GiST 索引最有用。一个很好的例子是电话号码，例如在美国，他们使用以下格式 :

l 3 位区号

l 前缀为3 位数字（与电话运营商的交换机有关）

l 行号的4 位数字这意味着您在第一组3 位数，第二组 3 位数周围有一些自然的聚类，然后数字可能会以更均匀的分布散开。但是，由于电话号码的存在，一些区号比其他区号的饱和度要高得多。结果可能是树非常不平衡。由于预先的自然聚类和数据的不均匀分布，像电话号码这样的数据可以作为 spgist 的一个很好的例子。

BRIN-（区块范围索引）

对于按顺序排列的大型数据集。块范围是一组彼此相邻的页面，其中所有这些页面的摘要信息存储在索引中。块范围索引可以专注于一些与SP-GiST 相似的用例，当对数据进行自然排序时，数据往往非常大，最好使用它们。譬如有十亿记录表，尤其是时间序列数据， BRIN 可能会提供有效帮助。如果要查询自然分组在一起的大量数据，例如几个邮政编码的数据（然后汇总到某个城市），则 BRIN 有助于确保相似的邮政编码在磁盘上彼此靠近。当您拥有非常大的数据集（例如日期或邮政编码）时，BRIN 索引可让您快速跳过或排除许多不必要的数据。此外， BRIN 被维护为相对于整体数据大小而言较小的索引，这使它们在处理大型数据集时非常有优势。

结论

在与Oracle 的企业平台和业务解决方案竞争时， PostgreSQL 具有一些主要优势。将 PostgreSQL 作为开源 RDBMS 的首选是绝对可信赖的，因为它几乎像 Oracle 一样强大。 Oracle 很难被击败（这是一个很难接受的事实），并且抛弃技术巨头的企业平台也不容易。当系统为您提供能力和生产成果时，这可能是一个难题。但有时需要在某些情况下必须做出选择，因为对平台的持续过度投资可能会超过其他业务层优先级的成本，从而影响进度。可以选择 PostgreSQL 及其底层平台解决方案来帮助您降低成本，减轻预算问题；而且所有的变化都不算大。