腾讯云国际版 PostgreSQL 实战：27 个规格怎么选、账单怎么算（2026）

腾讯云国际版 TencentDB for PostgreSQL 的规格单价其实是按内存线性定出来的：标准档每 GiB 内存每月 18.86 美元，1 核 2 GiB 包月 37.72 美元，8 核 64 GiB 包月 925.76 美元，而 8 核 16 GiB 只要 266.12 美元——比 4 核 16 GiB 的 301.76 美元还便宜 35.64 美元，是同内存下更划算的一档。本文用一份 2026-10-18 的官方定价页快照，把 27 个规格档位、三条产品线、磁盘的地域价差、备份超额计费和 Sysbench 基准放在一起算清楚，并给出从创建实例到 psql 连接再到只读实例扩容的完整操作路径。结论是：小规格的每美元 QPS 最高，48 核 480 GiB 的每美元 QPS 只有 1 核 2 GiB 的 1/14，选型的关键不是"买大"，而是先想清楚内存配比和地域。

Meta Description: 腾讯云国际版 PostgreSQL 实测：27 档规格单价按内存线性（18.86 美元/GiB），8c16G 比 4c16G 更便宜，磁盘地域差价 2.6 倍，附建实例、psql 连接、备份计费与成本核算。

关键词： 腾讯云国际版, TencentDB for PostgreSQL, 云数据库选型, PostgreSQL 规格价格, 只读实例, 备份计费

一、数据库家族的最后一块空缺：为什么现在写 PostgreSQL

站内已经把腾讯云的数据库产品线写了大半：MySQL 与 Redis 的基础篇、TDSQL 分布式篇、MongoDB 文档库、CTSDB 时序库、TcaplusDB 宽表、以及 DTS 迁移和 DBbrain 自治运维。唯独缺了关系型数据库里生态最厚的那一支——PostgreSQL。

这不是因为 PostgreSQL 不重要，恰恰相反。当业务从"单表增删改查"走到"JSONB 半结构化字段 + 地理围栏 + 窗口函数报表 + 全文检索"同时出现的阶段，MySQL 的替代方案往往是拆表、加中间件、再补一个 ES；而 PostgreSQL 用扩展就能覆盖大半。腾讯云国际版对 PostgreSQL 的支持也相当完整：本地盘主实例覆盖 11 到 18 全部大版本，云盘版覆盖 13 到 18，规格从 1 核 2 GiB 一路开到 156 核 960 GiB，连接数上限 40000，单实例磁盘最大可到 32000 GB。

对企业出海场景，这条产品线还有两个不太被提及的实际价值：

• 版本节奏跟得上上游。 大版本覆盖到 18，意味着可以用上 PostgreSQL 15 之后的 MERGE、逻辑复制的行过滤、以及 17 的增量备份基础能力，不必为了一个新语法等云厂商排期。
• 和 CVM、CLB、DTS 处在同一张网络平面里。 内网地址是 VIP，主备切换时 IP 不变，这一点在写连接池配置时非常关键（第五节会展开）。

下面这张表是本文后续所有成本计算的前提，先记住它的三个维度：本地盘还是云盘、主实例还是只读实例、按量还是包月。

一句话选型：要读扩展就选本地盘主实例（云盘版挂不了只读实例）；单库要 8000 GB 以上存储或需要频繁扩盘就选云盘版，但要做好"读扩展靠应用层分库"的心理准备。

二、三条产品线先分清：本地盘主实例、只读实例、云盘版

很多团队第一次买腾讯云 PostgreSQL 时踩的坑，是把"云盘版"当成"本地盘的高配版"。它们其实是两条独立的产品线，差异不在性能高低，而在架构约束。

本地盘主实例是双机高可用架构，主备两台物理机，数据落在本地 SSD 上，主备之间做同步复制。它的存储上限受物理机盘位限制，所以单实例 8000 GB 是常规天花板——只有 48 核 480 GiB 这个规格，在上海的 2 至 8 区、广州的 4、6、7 区可以开到 16000 GB。它的 IOPS 随规格线性抬升，官方给出的示例是 8 核 32 GiB 对应 28000 IOPS、48 核 480 GiB 对应 120000 IOPS、64 核 384 GiB 达到上限 150000 IOPS。

只读实例是单节点架构，不是双机高可用。这一点必须写进架构文档：只读实例所在的物理机故障时，它不会自动切换，只能重建。它的价值在于承担报表、全量导出、BI 直连这类"重查询"流量，把主实例的 CPU 让给交易型请求。约束有三条——最多 6 个、必须与主实例同地域、只能挂在本地盘主实例下面。

云盘版主实例的存储走的是云硬盘，所以盘可以独立扩容到 32000 GB，规格却只到 32 核 64 GiB。它最大的限制是不支持挂只读实例。如果你的读扩展方案是"加只读实例顶住查询"，那云盘版从一开始就不该进候选名单。

这三条线的价格关系也需要说清：只读实例按同规格档位计价，但国际站定价页的 Instance Type 下拉被 WAF 覆盖层挡住，无法切到 Read-Only Instance 抓取逐档单价（2026-10-18 与 2026-10-29 两次尝试均失败）。因此本文的价格表只覆盖本地盘主实例，只读实例的成本请按"同规格主实例价"估算，并在购买页核对。

三、27 个规格档位怎么收敛：单价其实按内存线性

腾讯云国际版 PostgreSQL 本地盘主实例在定价页上一共 27 个档位，从 1 核 2 GiB 到 156 核 960 GiB。硬记这 27 行没有意义，因为它们的定价规律非常简单：标准档的每 GiB 内存月价恒定为 18.86 美元，CPU 核数不额外计价。

把这条规律写出来之后，选型就变成一个二维问题：先定内存（它决定价格），再定核数（它决定并发处理能力）。下表是从定价页取到的 11 个常用档位（USD，本地盘主实例，按量三档为每小时单价）：

从这张表里能读出四个不太直观的结论，每个都用脚本复算过：

第一，按量三档是固定比例。 T2 = T1 × 0.75，T3 = T1 × 0.50，全部 11 行严格成立（8 核 64 GiB 因只保留两位小数，比例是 0.752）。T1 对应"用不到 4 天"，T2 对应"用 4 至 10 天"，T3 对应"整月开"。这解释了为什么短期压测要选按量而不是买包月——按量 T3 的小时价乘以 725.4 小时才等于包月价，用不满 30 天时按量更省。

第二，包月没有任何"长周期折扣"。 包年 = 包月 × 12，三年 = 包月 × 36，五年 = 包月 × 60，逐行验证完全相等（1 核 2 GiB 包月 37.72，包年 452.64，正是 12 倍）。所以长期付费的唯一价值是把"按量 T1/T2 的高单价"换成 T3 单价——如果你本来就是整月开机，包月和按量 T3 在 725.4 小时这个点上打平，再长就只赚在"锁价"上。

第三，8 核 16 GiB 比 4 核 16 GiB 便宜。 同样的 16 GiB 内存，4 核要 301.76 美元，8 核只要 266.12 美元，差 35.64 美元（11.8%）。这是定价页上唯一一处"加核反而降价"的位置，每 GiB 月价 16.63 低于标准线的 18.86。

第四，8 核 64 GiB 是全表每 GiB 最便宜的一档。 它的每 GiB 月价是 14.46 美元，比标准线低 23.3%。更关键的是它和相邻档位 8 核 48 GiB 的关系：多 16 GiB 内存只多 20.48 美元，折合 1.28 美元/GiB，只有标准单价的 6.8%。如果你的业务是"缓存命中率不高、IO 又打满"的形态，从 8 核 48 GiB 升到 8 核 64 GiB 是这张表上性价比最高的一次升档。

反过来说，12 核 24 GiB 的每 GiB 月价 17.69、包月除以 T3 只有 530.1 小时（标准档是 725.4 小时），说明这一档的包月价已经做过折算——它适合"核数不够但内存够用"的 CPU 密集场景，比如大量短事务、复杂 JOIN、或者并发连接数很多但每连接工作集很小的 API 网关型业务。

四、从零创建实例：七个必须做对的选择

控制台路径是 PostgreSQL 控制台的实例列表，点"新建实例"。这个表单有七个字段，其中三个一旦选错就只能重建（地域、VPC、磁盘类型），所以值得逐项过一遍。

第 1 步，选地域和可用区。 地域决定了三件事：与 CVM 的网络延迟、磁盘单价（第十节详述）、以及公网地址是否可开。国际站支持开公网地址的地域是北京、成都、重庆、广州、香港、南京、首尔、上海、新加坡、东京、法兰克福、弗吉尼亚、硅谷这 13 个。如果你的运维要从办公室直连数据库，而业务又落在没有公网能力的其他地域，那就必须提前准备跳板机或 VPN，不要等上线前才发现连不上。

第 2 步，选 VPC 和子网。 数据库实例的 VPC 创建后不可更改。这里的常见错误是"先建数据库、后建 CVM"——等到 CVM 才发现不在同一个 VPC，只能走对等连接（同账号同地域可以，跨地域就要上云联网），多一跳网络、多一份配置、多一条排障路径。正确顺序是先规划好 VPC 网段，再让 CVM 和数据库都落进去。

第 3 步，选版本。 本地盘主实例覆盖 11 到 18，新项目建议直接上 16 或 17。理由是 15 之后才有 MERGE 语句和逻辑复制的行过滤，16 起查询并行度与 vacuum 的调优空间明显改善，而 18 太新、部分扩展的编译产物还不齐。如果是从自建库迁移，用 DTS 做迁移时版本只能升不能降，先在测试实例上跑一遍兼容性再说。

第 4 步，选规格。 按第三节的规律，先按内存定档。经验值是：业务数据工作集（不是磁盘总量）能被内存装下 60% 以上时，缓存命中率才会明显高于磁盘读；装不下的部分就要靠磁盘 IOPS 兜。所以先估工作集——比如 200 GB 热数据，就该从 128 GiB 内存往上看（对应 20 核 128 GiB 或 24 核 192 GiB 档），而不是从 8 核 32 GiB 起步。

第 5 步，选磁盘容量和类型。 本地盘单实例 10 GB 起、常规上限 8000 GB；云盘版 20 GB 起、上限 32000 GB。这里有个容易忽略的细节：磁盘容量与 IOPS 不是一回事。官方给的 IOPS 数字是按规格（核数/内存）给的，8 核 32 GiB 是 28000，而不是按磁盘大小给的。所以"加大磁盘换 IOPS"在本地盘上不成立，要提 IOPS 只能升规格。磁盘容量主要解决的是数据增长和 WAL 堆积的空间问题。

第 6 步，配安全组。 默认安全组往往只放了 22 和 80，5432 要手动加。生产环境不要写 0.0.0.0/0，而是放 CVM 所在子网的网段。这一点和 NAT 网关/EIP 那套公网出口规划是同一个思路：能用内网就别开公网。

第 7 步，设置初始化账号。 管理员用户名默认 postgres，密码在创建时设定，之后可以在控制台的账号管理里重置。密码请直接进密码管理器，不要写在工单或群聊里。

七步走完，实例通常 3 至 8 分钟创建完成。创建后先去实例详情的"基础信息"里抄下内网 IPv4 地址和端口（默认 5432），后面所有连接都从这两个值出发。

五、连接实例：内网 VIP、公网地址与 psql 三条命令

腾讯云 PostgreSQL 提供两种连接方式：内网地址和公网地址。内网地址是唯一推荐的生产用法，公网地址只适合开发和临时运维。

内网连接的关键特性是：实例详情页显示的内网 IPv4 是一个 VIP，访问请求统一由接入网关集群转发，而不是直连数据库物理机。这带来的直接好处是——主备切换、宿主机故障迁移时，这个 IP 不变。所以连接池里写死内网 IP 是安全的，不需要像自建主从那样配多个地址做故障转移。

标准连接方式是在同 VPC 的 CVM 上装 psql 客户端，然后一条命令：

psql -U postgres -h 10.0.0.12 -p 5432 -d postgres

-h 后面填实例详情页的内网地址，-p 是端口（默认 5432），-d 是库名，初始只有 postgres 这个库。如果 CVM 上没有 psql，CentOS 系可以装 postgresql 客户端包，Debian 系装 postgresql-client，只要主版本号不低于服务端即可。

公网连接需要手动开启，路径是实例详情页的"基础信息"里找 Public IPv4 Address，点 Enable，确认后等状态从 Processing 变成正常。开通后用同一个 psql 命令换掉 -h 的值即可。三条硬约束要记住：

• 公网地址只有主实例支持，只读实例没有公网入口；
• 只有第四节列出的 13 个地域可以开；
• 开了公网就等于把数据库暴露在互联网上，必须同时收紧安全组，最好再加白名单。

连上之后的第一件事不是建表，而是确认权限模型。PostgreSQL 的权限是"库级 + schema 级 + 表级"三层，云上实例默认只给你一个超级用户 postgres，直接用它在生产环境跑业务是常见的安全隐患。建议按下面的顺序建立最小权限账号：

CREATE ROLE app_rw LOGIN PASSWORD 'replace-with-strong-password';
CREATE DATABASE appdb OWNER app_rw ENCODING 'UTF8' TEMPLATE template0;

-- 只读账号，给报表和 BI 用
CREATE ROLE app_ro LOGIN PASSWORD 'another-strong-password';
GRANT CONNECT ON DATABASE appdb TO app_ro;

-- 在 appdb 内执行：限定 schema 权限并设置默认权限，避免新表漏授权
-- GRANT USAGE ON SCHEMA public TO app_ro;
-- GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro;
-- ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO app_ro;

上面三行用注释形式给出，是为了提醒一个真实踩过的坑：GRANT SELECT ON ALL TABLES 只对已存在的表生效，之后新建的表不会自动继承。必须补 ALTER DEFAULT PRIVILEGES，否则新表上线当天报表就会报权限错误。这一段要在 appdb 库内执行，在 postgres 库里执行对 appdb 的 schema 无效。

还有一个连接层的常识值得写进运维手册：云数据库的单实例连接数上限是 2048 至 40000（随规格变化），但真正先撞墙的通常不是数据库，而是应用侧连接池。一个 20 个 Pod 的服务、每 Pod 50 连接，就是 1000 连接，看起来远没到上限，可 PostgreSQL 是进程模型，每个连接一个后端进程，内存开销随连接数线性上涨。经验配置是每 vCPU 对应 4 至 8 个活跃连接，其余全部走连接池排队。

六、备份与日志计费：700% 免费额度只是测试期

这是整篇文章里最容易让人算错钱的一节，因为官方文档的措辞里藏了一个时间条件。

腾讯云 PostgreSQL 的备份空间按地域汇总计算，免费额度是"该地域所有主实例存储容量之和"的倍数。文档原文写的是：备份计费处于测试期时，免费额度为存储总容量的 700%；正式收费后降为 100%。也就是说，如果你按 700% 去做容量规划，一旦正式计费落地，免费额度瞬间缩到七分之一，超额部分立刻开始计费。

超额部分的单价是：

两个执行细节会影响账单精度：超额不足 1 GB 不计费；不足 1 小时按 1 小时算。按每月 730 小时折算，海外地域每 100 GB 超额备份的月成本是 9.71 美元，500 GB 是 48.55 美元，1 TB 是 97.09 美元。同一档在中国大陆是 43.07 美元（500 GB），差 12.7%。

举一个能直接套用的例子。假设在新加坡买了 3 台主实例，磁盘各 500 GB，合计 1500 GB。正式计费后免费备份额度是 1500 GB。如果实际备份占用（数据备份 + 日志备份之和）是 2000 GB，超额 500 GB，月费 48.55 美元；如果误以为额度是 700%（即 10500 GB），就会认为"永远不花钱"，直到账单出来才发现每月多 48.55 美元。

控制备份成本有四个手段，按性价比排序：

1. 缩短日志备份保留期。 日志（WAL）备份量通常远大于数据备份，保留 7 天和保留 30 天的差异可能是几倍。恢复点目标（RPO）真的是 24 小时的业务，没必要留 30 天日志。
2. 降低全量备份频率。 每周一次全量 + 每日增量，比每日全量省得多。
3. 把冷备份归档出去。 超过 90 天的合规备份可以导到对象存储做生命周期分层，成本比数据库备份空间低一个量级。
4. 按地域合并实例。 因为免费额度是地域内求和，同一地域内的实例越多、总存储越大，免费额度越大。把分散在多个地域的小实例集中到一两个地域，能白白多出额度。

审计日志是另一条独立计费的线，走的是单独的计费文档（国际站 PostgreSQL 文档树的审计计费页）。开启数据库审计会把 SQL 明细写进日志服务，费用按写入量与存储量计——所以在生产上开审计之前，先确认"审计策略只记 DDL 和高危语句"，不要一上来就记全量 SELECT，那会把成本推到不可控。

七、只读实例：读扩展的边界条件

只读实例承担的是"重查询分流"这个明确职责：报表、全量导出、BI 直连、灰度压测。它不是高可用组件，也不该被当成"第二个主库"来用。

创建路径在主实例详情页的"只读实例"标签下，选规格、选可用区，创建后得到一个独立的内网地址，应用侧按读写分离的规则把只读流量指向它。四个硬约束必须先确认：

• 最多 6 个，超过这个数量就只能靠应用层分库或者上分析型数据库；
• 必须与主实例同地域，跨地域的读扩展只能走只读副本之外的方案（比如 DTS 订阅 + 异地库）；
• 只能挂在本地盘主实例下面，云盘版主实例不支持；
• 单节点，无自动故障切换，物理机故障时只能重建，重建期间读流量要回切主库。

所以只读实例的正确用法是"可降级的读分流"：应用侧必须能容忍只读地址不可用并回退到主库，否则加只读实例反而增加了一个故障点。

扩容的优先顺序建议是这样——这条顺序比买什么规格更重要：

1. 先看慢查询。80% 的"性能不够"其实是缺索引或 SQL 写错，加只读实例只会把慢查询复制到第二台机器上。
2. 再调参数。云上实例的 shared_buffers 默认值往往偏保守，官方参数模板里有按规格给出的推荐值，先套模板。
3. 然后加只读实例。把报表类查询挪走，主实例的 CPU 立刻下降。
4. 最后才升规格。升规格有停机窗口，而且按第三节的规律，升规格的每 GiB 单价并不下降（除 8 核 64 GiB 那一档），属于最贵的优化手段。

八、性能基线：官方 Sysbench 数字怎么读才不误导

腾讯云官方在文档里公布了 PostgreSQL 的 Sysbench 压测结果（测试方法见测试方法页，结果见测试结果页，页脚标注的最后更新日期是 2024-08-09，内核版本 V14.2）。这组数字非常有用，但有两个前提必须同时说清，否则会被误读。

前提一：测试是"全缓存"模式，也就是数据集完全装在内存里，压的是 CPU 和锁，不是磁盘。所以它代表的是"内存够用时的上限"，不代表你的磁盘型负载。前提二：V14.2 不是当前主流版本，16 和 17 在并行查询、JIT、vacuum 上都有改进，实际表现会更好一些，但不要拿这组数字去做版本对比。

三段边际收益，全部按脚本复算：

• 1 核 2 GiB → 4 核 16 GiB：QPS 涨 6.53 倍，价格涨 8 倍，边际每美元 446 QPS。这是全表最划算的一段扩容。
• 4 核 16 GiB → 8 核 32 GiB：QPS 只涨 1.58 倍，价格涨 2 倍，边际每美元 266 QPS。已经开始递减。
• 8 核 32 GiB → 48 核 480 GiB：QPS 涨 1.63 倍，价格涨 15 倍，边际每美元 16.3 QPS。这一段基本不该买。

结论非常明确：从 1 核 2 GiB 到 8 核 32 GiB，规模扩大 8 倍（按核数），QPS 涨 10.3 倍，价格涨 16 倍；再往上到 48 核 480 GiB，QPS 只多 63%，价格却是 15 倍。也就是说，超过 8 核 32 GiB 之后，垂直扩容的性价比断崖式下跌，正确的做法是水平分片或者读写分离，而不是继续升规格。

每美元 QPS 从 564.9 掉到 39.5，差距 14.3 倍。这个数字反过来也说明一件事：小规格并不是"性能差"，而是"单位成本效率最高、单点能力最弱"。所以小规格适合多实例分片（比如按租户分库，每个租户一个 2 核 4 GiB），而不是把一个大业务塞进 1 核 2 GiB。

还有一个反直觉的点：TPS 与 QPS 的比值随规格下降。1 核 2 GiB 是 3551/21308 ≈ 1:6，48 核 480 GiB 是 59531/357198 ≈ 1:6——比值其实基本一致，看起来没变化。但如果看每美元 TPS，从 94.2 掉到 6.6，跌幅 14.3 倍，和每美元 QPS 同步。这说明大规格并没有"更适合写"或"更适合读"的偏向，纯粹是规模不经济。

九、成本核算：三种典型负载的月账单

把规格、磁盘、备份三块拼起来，就是一张真实的月账单。下面三个场景都按广州地域、本地盘、包月、整月开机计算，磁盘按 3.60 美元/10 GB/月：

同一套配置如果落在硅谷地域，只是磁盘单价从 3.60 变成 1.36，规格价不变：

这张表说明一件事：磁盘占比越高，地域选择对账单的影响越大。小型场景磁盘只占 32%，换地域省 20%；大型场景磁盘占 44%，换地域省 27%。如果业务本身面向欧美用户，把库放在硅谷既省磁盘钱又降延迟，是双赢。

再补一个短期项目容易算错的地方。假设只跑 10 天压测，用 4 核 16 GiB：按量 T1 是 0.832 美元/小时，240 小时合计 199.68 美元，比包月的 301.76 美元省 102.08 美元（33.8%）。但如果不小心按 T1 单价开满整月 730 小时，是 607.36 美元，正好是包月价的 2 倍——这正是三档阶梯存在的意义：用得越久，单价自动降档，但只有真的用满才降到底。用不满 30 天的项目，按量几乎总是更便宜；用满整月的项目，包月和按量 T3 在 725.4 小时处打平。

最后是备份。上面三个场景的磁盘分别是 100、500、2000 GB，正式计费后的免费备份额度就等于这三个数（按地域求和）。超出部分按 0.000133 美元/GB/小时计：小型场景只要备份不超过 100 GB 就是 0 成本；中型场景备份到 700 GB 就是 200 GB 超额、月费 19.42 美元；大型场景备份到 3000 GB 就是 1000 GB 超额、月费 97.09 美元。这三笔钱都不大，但会被漏算——因为它们在控制台的"备份"页，不在"实例"页。

十、磁盘单价的地域差：差价可达 2.6 倍

关于腾讯云国际版 PostgreSQL 的价格，有一个流传很广的错误认知："某些地域的实例更贵"。实测结论是相反的——把定价页的地域从广州切到新加坡、雅加达、硅谷、香港，实例规格的 USD 单价完全不变。变的只有磁盘。

也就是说，广州的磁盘单价是香港/新加坡/雅加达的 2.1 倍、硅谷的 2.6 倍。这个结论有很强的实操含义：同样一台 8 核 32 GiB + 500 GB 的库，放广州月费 783.52 美元，放硅谷 671.52 美元，一年差 1344 美元；如果盘是 2000 GB，一年差 5376 美元。而实例本身的 603.52 美元，无论放哪儿都一样。

还有一个验证细节值得一提：包月价并不严格等于按量价 × 725.4 小时。广州 0.0050 × 725.4 = 3.63，但包月标价是 3.60；新加坡 0.0024 × 725.4 = 1.74，包月是 1.70。官方在包月价上做了轻微的向下取整，所以长期跑的业务应该买包月，而不是按量，两者的小时当量分别是 720 和 708 小时左右，都低于 730 小时的自然月长度。

磁盘容量本身还有一层账：扩容是单向的，不能缩容。所以规划时按"12 至 18 个月后的数据量"来定，而不是按当下。如果磁盘类型、容量这类基础资源的计费方式需要更细的口径，可以参考站内这篇 云硬盘 CBS 计费与性能详解，它的按量与包月换算逻辑和数据库磁盘是一致的。

十一、踩坑清单：九个真实会遇到的问题

下面九条都在实际项目里出现过，按"现象 → 根因 → 处置"整理，可以直接贴进团队的上线检查表。

再补充两条不写在表里的经验。第一，跨账号访问要走组织单元，别用主账号 AK 硬编码在应用里，多账号治理的权限模型可以看 腾讯云组织与 TCO 治理。第二，数据库不要直接挂公网，需要外部访问时优先用 NAT 网关做固定出口，再配安全组白名单，出口规划见 NAT 网关与 EIP 指南。

如果你的项目同时跑 MySQL 和 Redis，选型逻辑可以对照 腾讯云 TencentDB MySQL 与 Redis 实战；如果单库确实顶不住写入，再考虑 TDSQL 分布式数据库，但那是另一个量级的成本决策，不要作为 PostgreSQL 性能不足的第一选项。

总结

这篇文章的核心不是"腾讯云 PostgreSQL 好用"，而是三组可以拿去做决策的数字：

定价规律：标准档每 GiB 内存月价恒定 18.86 美元，CPU 不额外计价；包月除以 T3 单价恒为 725.4 小时；包年/三年/五年没有任何额外折扣。三个例外档——8 核 16 GiB（16.63）、12 核 24 GiB（17.69）、8 核 64 GiB（14.46）——是全表最值得记住的性价比点，尤其是 8 核 48 GiB 升 8 核 64 GiB 只多 20.48 美元。

规模规律：每美元 QPS 从 1 核 2 GiB 的 564.9 掉到 48 核 480 GiB 的 39.5，差 14.3 倍；从 8 核 32 GiB 再往上，QPS 只多 63%、价格却 15 倍。所以 8 核 32 GiB 是垂直扩容的实际天花板，再往上应该分片或读写分离。

地域规律：实例规格全球同价，只有磁盘随地域变——广州 3.60、香港/新加坡/雅加达 1.70、硅谷 1.36 美元/10 GB/月，广州是硅谷的 2.6 倍。磁盘占比越高的库，迁地域省的越多。

如果你正在做选型，建议的动作顺序是：先用第三节的表按内存定档（而不是按核数），再按第九节算三档场景的月账单，然后确认地域的磁盘价与公网能力，最后才回控制台下单。整个过程中最容易被跳过、也最容易超支的一步是备份额度——记住 700% 只是测试期，正式计费是 100%。

需要继续深入的话，扩容路径看 CVM 选型指南，迁移方案看 DTS 数据迁移，日常运维看 DBbrain 自治诊断。

价格说明：本文规格与磁盘单价取自腾讯云国际站定价页（PostgreSQL、本地盘主实例、广州地域）2026-10-18 的渲染快照，按量 T1/T2/T3 与包月价为页面实测值；2026-10-29 复核时该页价格由前端动态计算、仅能取到规格骨架，故实时报价请以下单页结算为准。所有派生数字（每 GiB 单价、每美元 QPS、月账单合计、备份超额费用）均由脚本按上述单价复算，非估算。价格可能变动，请以腾讯云官网为准。

本文由 4.chengzicloud.cloud 提供，点击访问首页了解更多