数据库选型从来都不是比拼特性清单，而是看数据模型与应用形态是否匹配。PostgreSQL作为关系型数据库的代表，用行和列组织数据，强调约束、事务与查询优化器；Cassandra则采用宽列存储模型，以分区键为锚点把数据分布到整个集群，用空间换取写入能力。两者看起来都属于数据库，但底层思路截然不同。
一、数据模型：关系表与宽列的本质差异
PostgreSQL的数据模型是严格的关系模型。一张表由固定列组成，每一行都必须符合表结构，新增字段需要执行ALTER TABLE操作。这种约束保证了数据的结构性，配合外键、唯一约束和CHECK约束，可以在数据库层面完成大量完整性校验。业务系统发展初期，这种模型能显著减少应用代码的出错概率。
Cassandra的宽列存储则不同。它虽然暴露了类似SQL的CQL语法，但表结构更接近稀疏矩阵。每一行由分区键唯一标识，除了主键之外，其他列可以分布在不同的SSTable文件中，不同行允许拥有不同的列集合。宽列模型的真正含义，是一个分区键下可以挂载海量列，列名甚至可以动态生成。
以下分别是PostgreSQL和Cassandra创建订单表的示例，能直观看出两种建模思路的差异。
CREATE TABLE user_orders (
user_id BIGINT NOT NULL,
order_id BIGINT NOT NULL,
product_name TEXT,
amount DECIMAL(10,2),
created_at TIMESTAMP DEFAULT now(),
PRIMARY KEY (user_id, order_id)
);
CREATE TABLE user_orders (
user_id bigint,
order_id bigint,
product_name text,
amount decimal,
created_at timestamp,
PRIMARY KEY ((user_id), order_id)
) WITH CLUSTERING ORDER BY (order_id DESC);
很多从关系型数据库转过来的开发者，第一次看到CQL建表语句时会困惑，为什么主键要分成两个部分。实际上第一个括号里的user_id是分区键，决定数据存储在哪个节点；order_id是聚簇键，决定分区内同一个分区键下的排序方式。这种设计让Cassandra可以在分布式环境中按主键快速定位数据，但也意味着查询模式必须围绕主键设计。
二、写入性能与横向扩展：Cassandra为何写得更快
PostgreSQL写入依赖B+树索引和WAL日志。每一次写入都需要更新表数据和所有相关索引，事务提交时需要确保WAL落盘，在高并发场景下磁盘IO会成为主要瓶颈。通过升级硬件、配置SSD或使用更快的磁盘可以缓解，但单机写入通道的物理上限始终存在。
Cassandra的写入路径完全不同。数据先追加到内存中的Memtable，同时写入CommitLog做持久化保障，达到阈值后再批量落盘为SSTable。整个过程是顺序IO，不需要随机更新已有数据页，也没有索引回写开销。配合一致性哈希和复制因子，写入请求可以在集群内水平分摊，理论上节点增加，写入吞吐接近线性增长。
这里需要说明，Cassandra的高写入吞吐是有代价的。默认配置下，副本数通常是3，一条写入至少需要等待本地节点和远程节点返回确认，可用性和一致性之间需要在读写一致性级别上做平衡。如果对数据不丢失要求极高，可以把写一致性级别设为QUORUM，但代价是写入延迟上升。
三、查询能力与事务支持：PG的复杂查询与ACID优势
PostgreSQL的查询能力是关系数据库的集大成者。丰富的索引类型（B-tree、Hash、GIN、BRIN）、窗口函数、CTE、递归查询、物化视图，让它在报表统计、数据分析、地理信息处理等场景中非常顺手。开发者可以使用JOIN在数据库端完成多表关联，优化器会基于统计信息选择执行计划。
Cassandra的CQL并不支持JOIN，也没有子查询和窗口函数，WHERE条件必须包含分区键，或者至少用聚簇列过滤。设计宽表时需要把查询维度提前建模，把所有查询条件映射到主键结构中。这种限制让Cassandra查询路径非常稳定，却也使它很难处理即席查询和报表类需求。
例如，如果表的主键是(user_id, order_id)，要按order_id查询单条订单，CQL会直接报错，因为查询条件没有包含分区键user_id。
SELECT * FROM user_orders WHERE order_id = 1001;
这逼迫应用层必须维护额外的索引表，或者使用Cassandra的物化视图来兜底。事务方面两者差距更明显。PostgreSQL完整支持ACID，默认的读已提交隔离级别足够应对绝大多数业务，加上可序列化快照隔离，可以实现复杂的一致性约束。Cassandra只提供行级别的原子性，跨分区事务需要依赖BATCH，但官方文档明确表示BATCH并非分布式事务，它只能保证原子性，不能保证隔离性。对于订单支付、库存扣减这类强一致场景，Cassandra并不是合适的选择。
四、选型建议：不同场景下的数据库方案
综合来看，PostgreSQL适合数据关系复杂、查询多变、需要事务保障的业务系统，比如电商后台、ERP、财务系统、CRM。它的单机性能在大多数场景下足够，并且可以通过表分区、连接池、读写分离等手段水平扩展。如果业务持续增长，还可以借助Citus等扩展把PostgreSQL升级为分布式数据库。
Cassandra在时间序列数据、IoT设备上报、用户行为日志、消息流缓存等场景下更有优势。它的写入模型天然适配高吞吐、低时延的海量数据采集，查询模式简单且固定时，数据模型可以围绕主键精准设计。同时，Cassandra的运维门槛明显高于PostgreSQL，节点替换、压缩调优、跨数据中心部署都需要专门的运维经验。
选型时不必把两个产品放在对立面。很多大型系统会在同一技术栈中同时使用PostgreSQL和Cassandra：PostgreSQL保存订单、交易等核心业务数据，Cassandra接收海量埋点和IoT数据，再通过数据管道汇总到分析系统。数据库选型的答案，永远取决于查询模式和写入吞吐之间的平衡，而不是数据库本身的名气。
PostgreSQLCassandra宽列存储修改时间：2026-08-19 07:48:46