MySQL发行商Percona推出PG发行版
digoal约 5 分钟本期播客
MySQL发行商Percona推出的PG发行版靠谱吗?
众所周知Percona是MySQL的发行商, 不过在MySQL被Oracle玩废之后, Percona就开始转投PG, 陆续推出了sysbench for PG, PG TDE 插件.
可参考我之前发过的文章( https://github.com/digoal/blog )
《PostgreSQL 12 tpcc 测试 - use sysbench-tpcc by Percona-Lab》 《Percona 开源 PostgreSQL 16+ TDE 插件》
不过其实早在2012, PG曾计划将TDE功能内置到内核, Patch都提交了, 不过因核心commiter提出无足够的test case质疑后被无情打回. 至今没有后续了. 核心组到底想干啥? 作啥妖?
可参考我之前发过的文章( https://github.com/digoal/blog )
《PostgreSQL 14 preview - TDE cluster_key_command 配置例子》 《PostgreSQL 14 preview - 支持TDE功能, 支持加密数据文件, 支持加密WAL日志文件》
难道PG的TDE要靠MySQL发行商了? 有啥不可以呢? 谁说percona只会MySQL, 识时务为俊杰, 赞percona!!! 如今percona其实已经是PG发行商了!!! 怪不得不见percona去参加MySQL的会议了
下面看看来自percona TDE的最新发文!
https://percona.community/blog/2025/11/28/tde-is-now-available-for-postgresql-18/
TDE 现已支持 PostgreSQL 18 | Percona 社区
早在十月份，在 PGConf.EU 会议之前，我解释了影响 PostgreSQL 18 中 TDE 迟迟未推出的原因。之所以需要进行解释，是因为用户对此充满期待，他们理应了解造成延迟的原因以及路线图的样子。在那篇博客文章中，我分享了由于 18.0 中新增的一项功能——Asynchronous IO (AIO，异步 IO) ，我们决定给自己一些时间，直到 18.1 版本发布后再提供支持 TDE 的构建版本。我们希望确保解决方案的最佳质量，这需要时间。
正如 PostgreSQL Development Group (PGDG，PostgreSQL 开发组) 路线图中所规划的那样，社区已于 11 月 13 日发布了 PostgreSQL 18.1。Percona 工程师不仅成功交付了与 PostgreSQL 18 更改兼容的 TDE，而且对其提供了完全支持。在我们的发行版中，我们也完全跳过了 PostgreSQL 18.0。第一个启用 TDE 的版本将是 Percona Distribution for PostgreSQL 18.1.1 (Percona PostgreSQL 发行版 18.1.1) ，使我们的构建版本直接与 PostgreSQL 18 的第一个次要版本保持一致。以下是关于新增功能的一些详细信息！
Percona PostgreSQL + TDE + AIO
今天，我们很自豪地宣布，Percona 现在发行的 PostgreSQL 18.1 从一开始就完全支持 TDE 和 AIO。
无需打补丁、无需变通方法、没有“实验性警告”。Encryption-at-rest (静态数据加密) 不仅仅与 AIO 兼容。它得到了支持、集成，并已为整个生态系统的生产部署做好准备，使强化的 PostgreSQL 环境能够自信地满足合规性要求。从 PostgreSQL 18.1 开始，Percona：
完全支持原生的 TDE (Transparent Data Encryption，透明数据加密) 提供与社区 PostgreSQL 保持一致的 AIO (Asynchronous IO，异步 IO) 启用版本 为企业部署提供生产就绪的软件包
TDE 成熟化，pg_tde 重返家园
在 2026 年，我们计划进行重大投入，以确保 TDE 能够为社区 PostgreSQL 持续发展。作为这项新重点的一部分，Percona 正在将 pg_tde 转移回其专属的“家”：
➡️ https://github.com/percona/pg_tde
这反映了 pg_tde 的新角色。随着 pg_tde 用户的不断增加，它不再能被视为填补 PostgreSQL 空缺的权宜之计。相反，我们希望将其视为 PostgreSQL 18+ 时代的一个补充性、高级加密层：
一旦准备就绪，即可提供针对数据静止时加密 (data-at-rest encryption) 的扩展功能 作为社区请求的集成的中心 一个提供反馈、评论和问题的安全空间，以帮助推动 TDE 的未来发展
发布这个新版本带来了一些真正的改进，尤其是在 KMS 集成 (Key Management Service integration，密钥管理服务集成) 方面。
KMS 改进
我们根据用户和客户的直接反馈扩展了 Key Management Service (KMS，密钥管理服务) 的功能。无论是通过 GitHub、Percona 社区论坛 (Percona Community Forums) 、活动还是直接对话 —— 感谢你们！你们的意见塑造了我们的路线图。
pg_tde 现可与 Akeyless KMS 配合使用
在实施零信任安全模型 (zero-trust security models) 的组织中，Akeyless 越来越受到关注。pg_tde 现已与 Akeyless 干净集成，能够利用 KMIP (Key Management Interoperability Protocol，密钥管理互操作性协议) ，在云端和本地部署中实现强大的密钥检索和生命周期管理。 ( https://www.akeyless.io/ )
支持 HashiCorp Vault 和 OpenBao 命名空间
Vault 和 OpenBao 用户现在可以在存储加密密钥时利用命名空间 (namespaces) 。
为什么命名空间很重要？
Multi-tenancy (多租户) ：隔离团队、环境或应用程序的密钥访问 Security boundaries (安全边界) ：每个命名空间都可以执行自己的身份验证和审计策略 Cleaner CI/CD (Continuous Integration/Continuous Deployment，更清晰的持续集成/持续部署) ：开发/预发布/生产环境可以共享一致的密钥路径结构 Delegation & separation of duties (授权与职责分离) ：安全团队管理根策略，而应用程序团队管理自己的命名空间
在大型组织中，命名空间支持不仅仅是一种便利，它是一种要求。OpenBao 很早就优先考虑了这一点，并在 2025 年 5 月发布了它。随着 pg_tde 现在对命名空间的原生支持，PostgreSQL 部署获得了企业级密钥管理灵活性 (enterprise-grade key management flexibility) 。
接下来会发生什么？
我们的承诺保持不变：TDE 必须成为 PostgreSQL 中一流的、易于访问的、社区驱动的功能。分享您的反馈，让我们共同实现这一目标！我们可以以完全的开放性和透明度共同构建 PostgreSQL 开源 TDE 解决方案 (open source TDE solution for PostgreSQL) 的未来！
凛冬将至，但任何天气都无法阻止我们！敬请期待 TDE 的更多新进展：
Key length configurations (密钥长度配置) 即将推出——敬请期待很快就能在 TDE 中使用 256 位密钥 (256-bit keys) ！ 扩展的 KMS 集成 (Key Management Service integrations) ——我们已经在研究云 KMS 支持 (cloud KMS support) 。请分享您正在使用哪些服务以及您希望支持哪些用例！ 改进 pg_tde 加密目标 (pg_tde encryption targets) ——接下来将探索临时文件 (temporary files) ，随后是与社区 PostgreSQL 的系统目录 (system catalog) 兼容性 与社区 PostgreSQL 的兼容性——我们希望推动将 pg_tde 所需的任何更改纳入社区 PostgreSQL 中，以便该扩展可以供所有 PostgreSQL 构建版本的用户运行！
冒着重复的风险，值得强调的是，我们基于您的反馈进行构建，所以请不要客气！
percona 还是一如既往的很会和用户互动:
Percona Community Forums: https://forums.percona.com/c/postgresql/25 pg_tde GitHub Repo: https://github.com/percona/pg_tde Issues & Discussions https://github.com/percona/pg_tde/issues https://github.com/percona/pg_tde/discussions
你怎么看percona转投pg, 怎么看待percona的pg tde 插件? 欢迎留言!