数据库托管最佳 VPS：按工作负载选择配置

两个数据库占用同样的磁盘空间，也可能需要不同的 VPS。一个反复读取少量行，另一个持续写入、构建大型索引，或必须在故障后快速恢复。选择数据库 VPS 应先看这些差异，再比较供应商。

购买非托管 VPS，也意味着负责数据库运行。PostgreSQL、MySQL 和 MariaDB 的内存预算不同；恢复能力应与主服务器一起设计。初始配置必须为备份和维护留出余量，并通过代表性负载测试。

先衡量数据库负载，再选择套餐

选择 CPU、内存和磁盘前，测量活跃数据与索引、峰值并发查询、增长量及恢复需求。按实测瓶颈增加资源。共用主机时，计入维护空间和应用峰值消耗；预算必须兼顾繁忙期和日常运行。

工作集是访问频繁、值得保留在内存中的数据和索引。存储总量还包括冷数据。打开的连接也不等于活跃查询：空闲客户端与并发排序对内存和 CPU 的要求不同。记录两者，以及查询形态和读写比例。

从代表性的繁忙时段制定采购要求：

• 如果应用共用 VPS，测量其内存峰值。
• 记录数据库和索引大小、工作集估计、并发操作，以及规划周期内的增长。
• 测量日志生成量，确定预计最大的索引构建、表重写或其他维护操作。
• 设定应用 p95 延迟目标、可接受的数据丢失窗口及恢复时间目标。
• 决定应用部署位置，测试其与数据库之间的路径。

PostgreSQL 的监控文档建议结合数据库统计和操作系统工具。记录 CPU、内存压力、磁盘活动及查询和提交耗时。即使空闲服务器检查正常，备份期间延迟上升仍需调查。

专用 vCPU 提供对已分配 CPU 资源的持续访问，并不代表独占整台物理服务器，也不确定存储 IOPS。分别评估 CPU 分配、内存容量和存储行为。如果实测要求超过现有 VPS，研究专用硬件，不要凭更大套餐的名称推断。

为 SQL 负载匹配初始配置

根据应用兼容性，将 PostgreSQL 16、使用 InnoDB 的 MySQL 8.4 或 MariaDB 11.4 作为备选示例环境。它们不可直接互换，也不表示最新版本。测试前记录已安装的补丁版本；示例不指定供应商镜像的部署版本。

将小应用与数据库部署在同一主机

假设数据库 3 GB、热数据 1 GB，并有五个活跃的简单索引查询，可测试 2 vCPU、4 GB RAM 和标称 60 GB SSD 或 NVMe。连接在本地，但应用和数据库的总峰值必须纳入同一内存预算。

假设读写比 90/10、每月增长 1 GB，备份时不运行长报表。共享 CPU 可用于容忍波动的预发布环境。持续争用导致响应不合适时选专用分配；后文生产套餐比较全部使用专用 vCPU。

建议的内存分配如下，全部单位为 GB：

将 MySQL 或 MariaDB 的 InnoDB 池纳入此预算。把专用数据库的内存比例套用到整台主机，会占用分给应用的内存。PostgreSQL 应在数据库配额及预留内分别计算共享缓冲区与操作内存。接受任一配置前，测量总峰值。

磁盘示例：系统/日志 5 GB、数据/索引 3 GB、引擎日志 4 GB、临时空间 3 GB、增长 6 GB，共 21 GB。剩余标称容量用于文件系统开销和临时工作，不能因此把保留的备份放在主节点。

通过本地套接字或 localhost 连接。在应用和备份同时运行时测试持久提交，包括要求操作系统将数据刷入持久存储的同步操作（fsync）。若负责人接受 24 小时恢复点目标 RPO（可丢失数据窗口）及四小时恢复时间目标 RTO，可建议每晚原生备份到节点外，并以演练证明恢复时长。内存、延迟或恢复预算不达标时，先诊断查询/索引，再分离、扩容或调整恢复设计。

独立部署事务型 SQL 数据库

应用运行在别处时，示例中的 12 GB SQL 数据库、6 GB 热数据可从 2 个专用 vCPU、16 GB 级 RAM 和 50 GB 级本地存储开始测试。假设 20 个活跃索引查询、短写入和低持续计算量；更重操作可能使预算失效。

假设读写比 90/10，连续三个月每月增长 1 GB。这是供应商表的参考负载。各套餐单位不同，分配前应比较实际可用内存与文件系统可用字节。

对于 PostgreSQL VPS，PostgreSQL 16 的共享缓冲区指南建议：至少 1 GB RAM 的专用数据库服务器，从系统内存的 25% 开始。PostgreSQL 还使用操作系统缓存。16 GB 预算示例：共享缓冲 4 GB、系统/代理 2 GB、查询/连接/维护预留 2 GB、文件缓存及余量 8 GB。

预留不等于 work_mem 设置。PostgreSQL 的查询操作内存文档说明：多个会话并行时，各排序和哈希操作可分别分配内存。哈希还使用 hash_mem_multiplier。根据允许的并发工作设限；单操作值过大，即便共享缓冲充足，也可能超出主机预算。

对于 MySQL VPS，Oracle 的MySQL 8.4 缓冲池指南通常建议系统内存的 50–75%，同时考虑操作系统和其他分配。此处测试 8 GB InnoDB 池，将剩余内存留给其他使用方和峰值工作。

MariaDB 的计算略有不同。其内存分配指南建议，以 InnoDB 为主时，从扣除系统/服务后可用 RAM 的 60–70% 开始。若可用 13 GB，即 7.8–9.1 GB，8 GB 初始池适合此例。MyISAM 或 Aria 缓存需另算。这些引擎预算是备选方案，不要相加。

磁盘预算：数据/索引 12 GB + 增长 3 GB + 系统 5 GB + 日志 4 GB + 临时/维护 8 GB = 32 GB。50 GB 级磁盘在文件系统开销前约余 18 GB。此例要求至少 15 GB 实测空闲；保留更多日志或更大重写会使其失效。

让应用与数据库靠近，在支持时使用经过测试的私有路径，并配置认证、访问控制和加密。检查 checkpoint、刷盘和备份期间的查询及持久提交延迟。分配独立备份存储，后文详述。查询/索引诊断后，若资源饱和、空闲空间不足或恢复目标不达标，应扩容。

为更大工作集或持续写入规划资源

假设数据库 100 GB、热数据 16 GB，可测试 4 个专用 vCPU、32 GB RAM 和 300 GB 级 NVMe，应用保持独立。此例允许 30 个活跃混合查询、60/40 读写比；增加资源前先测量执行和存储压力。

假设连续三个月每月增长 10 GB。PostgreSQL 预算：共享缓冲 8 GB、系统/查询/维护预留 4 GB、文件缓存及余量 20 GB。MySQL/MariaDB 可在其他预留后，以约 16 GB InnoDB 池作为备选。不要直接移植 PostgreSQL 参数。

存储还要容纳进行中的工作：数据/索引 100 GB + 增长 30 GB + 保留/排队日志 30 GB + 最大维护/临时操作 60 GB + 系统 10 GB = 230 GB，约余标称 70 GB。即便日常增长不大，更大的表重写也需重算。

PostgreSQL 的日常清理文档区分了让死行空间可复用的 VACUUM，以及创建新表副本、临时需要额外空间的 VACUUM FULL。磁盘仅略大于数据集，可能阻碍回收空间所需的维护。

将 CPU 执行、缓存压力、物理 I/O 与写延迟分别测量。测试包含临时写入及 checkpoint/刷盘阶段。NVMe 和专用 CPU 是配置说明，不保证 IOPS。使用邻近私有应用连接和独立恢复存储，测试可持续的备份及复制传输。日志生成加快会改变保留容量和网络需求。按实测约束增加核心、RAM 或磁盘，不要仅因下一档同时增加三者。

为生产环境增加恢复能力

可接受丢失 15 分钟数据、目标一小时恢复，需要超出主节点预算的设计。保留独立事务负载假设，再加入原生备份、恢复日志、独立存储及计时演练。这些是规划目标，只有演练才能证明达标。

PostgreSQL 的连续归档文档介绍基础备份与不间断 WAL 归档，用于时间点恢复。Oracle 的MySQL 恢复文档采用完整备份后应用二进制日志。MariaDB 的PITR 流程先恢复完整/增量数据，再重放二进制日志。这些 MySQL/MariaDB 流程必须启用二进制日志。

容量示例：每份未压缩完整/基础备份为 12 GB。保留三个每周基础备份，以及从最旧备份开始所需的连续日志。按最多 21 天、每天 2 GB 日志，加 20% 存储余量计算：

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

规划至少 100 GB 独立备份存储，不假设压缩。日志删除与备份到期、成功替换关联。验证基础备份和日志对每个承诺的恢复点都构成完整链。

使用独立目标上的备份，凭据和删除控制与主节点分离。供应商快照本身不能证明这条数据库原生恢复链。演练应创建干净目标、传输并恢复备份、重放日志、验证数据库/应用一致性，再切换应用路由。供应和传输时间也要计入。

更短停机目标可能需要独立部署、能承受完整负载的副本。另算其 CPU、RAM 和磁盘，定义提升、隔离旧主节点及客户端路由，并演练。复制不代替备份，单台 VPS 不等于高可用。若恢复超过一小时、归档滞后超 RPO、备用节点承载不足或备份空间接近预算，应调整设计。

何时选择托管 VPS

若无人响应数据库告警或在事故中恢复，应购买明确的运维覆盖。托管 VPS 可转移部分维护，但合同必须列出数据库任务。控制面板不证明覆盖；托管 VPS 与托管数据库不同。

托管与非托管 VPS 的责任差异，应落实到具体任务。以下是采购清单，不承诺所有服务都覆盖同样工作。物理基础设施仍归供应商；客户机软件与数据库运维必须明确负责人。

实用合同问题：“备份时数据库磁盘满了，谁诊断、恢复服务，并确认下次备份成功？”答案区分了支持渠道与结果责任。也要问引擎升级失败或误删时谁负责。

托管数据库有自己的引擎生命周期、备份及故障切换约定。若想转移恢复与升级工作，它可能更适合。不要从服务名称推断包含应用调优；除非合同另有规定，查询设计和应用行为仍需负责人。

每项任务只分配一次，设置升级路径和验收检查。将服务价格与可投入的时间、可用性比较。自主管理没有通用时薪，廉价计算账单无法处理无人负责的事故。

为非 SQL 负载选择 VPS

这些示例区分内存负载、文档存储与搜索索引。让应用靠近并测试连接，也测试到备份及所用副本的传输。

Redis 的管理指南警告：写密集场景保存 RDB 或重写 AOF 时，可能使用平常两倍内存，取决于被修改的页。因此 2 GB 数据集不能占满内存。持久化文档区分周期 RDB 快照与 AOF 写日志。按可接受丢失选策略，再测运行时内存和磁盘峰值。

MongoDB 的WiredTiger 缓存文档说明内部缓存和文件系统缓存。默认内部缓存取 50% × (RAM − 1 GB) 与 0.256 GB 中较大者。副本集指南建议三个持有数据的成员。仲裁节点投票但无数据。另配独立备份，并在连接应用前启用 MongoDB 身份认证。

Elastic 的JVM 设置文档建议自动调整堆。手动设置时，最小/最大值相同，且不超过可用内存 50%。小型集群韧性指南介绍两个有数据、可选为主节点的节点，加一个仅投票的仲裁节点。配置副本并把客户端路由到数据节点；仲裁增加投票，不增加数据副本。合并或保留耗尽磁盘余量时，先调整预算再加文档。

比较适合所需配置的非托管套餐

对独立事务型 SQL 示例，以至少 2 个专用 vCPU、16 GB 级 RAM 和 50 GB 级本地存储筛选。达标仅表示可进入测试。CPU/磁盘组合、单位及计费承诺不同，不能视为相同硬件或性能排名。

参考部署是德国或邻近中欧的自管 Linux，数据集小而内存预算大。邻近不代表应用延迟相同。支持时使用私有应用连接；报价保留标准公共 IPv4。假设传输低于所有列出的额度。

DigitalOcean 的套餐选择文档将 Memory-Optimized 列为 SQL/NoSQL 数据库及缓存选项。我推荐上述捆绑系列用于小磁盘、高内存场景。内存优化 VPS 并非 SQL 专用。若实测瓶颈是存储容量或持续存储需求，应另评估 Storage-Optimized 捆绑系列。

五款都达到参考下限，但额外 CPU 和磁盘不同。余量可能支持增长，却不能未经测试就证明数据库更快。Hetzner 列表不保证可订购库存。Akamai 说明 G7 Dedicated 使用 SSD。Vultr Optimized Memory 与共享 High Frequency Compute 是不同类别。

我们的专用资源分配适合此自管方案，价格如表。评估总价值前，比较各家资源、币种、计费承诺及 IPv4 费用。

总拥有成本为计算 + 地址 + 独立备份存储/请求/传输 + 恢复测试容量 + 可选备用节点。未知费用不等于零。比较前取得当前恢复服务价格，承诺计费周期前核对具体套餐、位置和升级路径。不要将四舍五入的月均价相乘来推算年度账单。

选定兼容 SQL 引擎后，我们的一键应用可缩短安装过程。PostgreSQL、MySQL 和 MariaDB 是分别选择的；选一个不会安装全部三个。部署仍自主管理，补丁、调优及恢复由您负责。

常见问题

PostgreSQL 缓存命中率能判断存储是否慢吗？

不能。PostgreSQL 的I/O 统计文档解释，数据库读取可由系统缓存满足，不必访问磁盘。结合命中率、系统 I/O 和查询耗时判断。单看命中率无法区分物理存储延迟与内核内存中的读取。

PostgreSQL 逻辑转储能用于基于 WAL 的时间点恢复吗？

不能。PostgreSQL 的连续归档要求说明，逻辑转储缺少重放 WAL 所需信息。转储恢复捕获时状态；WAL 时间点恢复需要合适的基础备份与连续 WAL 归档。按计划的恢复方法选择格式。

容器中的 MongoDB 缓存应使用主机总 RAM 吗？

使用容器可用内存。MongoDB 的容器内存指南警告，WiredTiger 有时无法识别更低的容器限制。缓存设在限制以下，为其他进程留空间；主机总 RAM 可能高估数据库实际可用内存。