数据库选择
把数据库配工作负载——OLTP、OLAP、KV、时序、搜索——而非"我们会的"。
为什么
全用 Postgres 直到不行——Postgres 上时序负载贵 InfluxDB 10 倍、图遍历慢 Neo4j 100 倍、KV 查找贵 Redis 5 倍。每数据库为工作负载形状优化，用错意味着你跟数据库斗而非用。正确选择由访问模式驱动（见 data-modeling），非"我们已有 Postgres"。话虽如此运维现实重要：跑 5 数据库贵，所以艺术是用最少数据库覆盖工作负载，长尾接受"够好"。
何时使用
当新工作负载不适配现有存储。半天。存储变瓶颈时重访。
如何做
1. 分类工作负载： - OLTP（事务、多小写读）→ Postgres/MySQL - OLAP（分析、少大聚合）→ BigQuery/Snowflake/ClickHouse - KV（键 → 值、亚毫秒）→ Redis/DynamoDB - 时序（带时间戳、高写）→ InfluxDB/TimescaleDB - 搜索（全文、分面）→ Elasticsearch/Meilisearch - 图（关系、遍历）→ Neo4j/Neptune 2. 查现有存储能否"够好"服务（如 Postgres+ts 扩展做时序） 3. 若否，评估新存储：托管选项？运维成本？迁移路径？ 4. 算加 vs 硬塞现有的 TCO（见 tco-analysis） 5. 偏覆盖所有工作负载的最少存储数——每新存储是运维开销 6. 把工作负载→存储映射记架构文档
示例
工作负载： 1. 用户/订单 CRUD（OLTP）→ Postgres（现有）✓ 2. 月收入分析（OLAP）→ Postgres 在 1 亿行慢 3. 实时指标（时序）→ Postgres 快膨胀 4. 商品搜索（全文）→ Postgres trigram 行但非优 选项： A. 全塞 Postgres：行，但 #2 40 秒、#3 月膨胀 500GB B. 加 ClickHouse（#2）+ Redis（#3）+ Meilisearch（#4）：3 新存储，1.2 千/月 C. 加 ClickHouse（#2）+ TimescaleDB（#3，Postgres 扩展）+ Postgres trigram（#4） 决策：C——1 新存储（ClickHouse）、1 扩展、接受"够好"搜索。 覆盖所有工作负载、最小化运维开销。
常见问题
- ⚠每工作负载加新数据库——终 7 数据库无团队能全运维；"够好"处合并。
最佳实践
- ✓多数系统起步 Postgres+Redis——覆盖 80% 工作负载；仅当一明显失败加专存储。
- ✓加新数据库前用 Postgres 扩展（TimescaleDB、PostGIS、pgvector）——获专化无运维开销。