PostgreSQL与Realm虽然都被归入数据库范畴，但两者的运行位置、数据组织方式和设计目标差异非常大。PostgreSQL是典型的服务端关系型数据库，通过TCP连接对外提供SQL服务；Realm则是嵌入到iOS、Android等客户端应用中的移动数据库，数据文件直接存储在设备本地。理解这一本质区别，有助于避免在选型时陷入二选一的误区。
架构定位：服务端集中式与移动端嵌入式
PostgreSQL采用客户端/服务器架构。数据库实例通常部署在独立的服务器或容器中，应用通过驱动建立网络连接，发送SQL语句并接收结果集。这种模式适合多用户并发访问同一份数据，依靠事务隔离级别、行级锁、预写日志等机制保证一致性。对移动应用来说，如果后端API已经用PostgreSQL作为主存储，移动端一般不直接连接PostgreSQL，而是通过HTTP接口间接读写。
Realm的架构完全不同。它以嵌入式库的形式随应用打包，数据库文件创建在应用的沙箱目录中。查询和写入都在进程内完成，不需要网络往返，也不依赖远程服务。Realm采用零拷贝的内存映射技术，读取数据时不会像传统ORM那样把整行复制到独立对象，而是直接访问底层存储。这个设计让它在移动设备上的读写延迟非常低，尤其适合需要频繁访问本地数据的场景。
需要注意的是，Realm并不替代服务端数据库。移动端本地库可以被用户通过备份、越狱或调试工具直接读取，任何写入本地Realm的数据都不能作为可信数据源。涉及计费、权限、库存等关键逻辑，仍应在PostgreSQL端做最终校验。
数据模型与查询语言对比
PostgreSQL使用关系模型，数据以表、行、列的形式组织，模式通过DDL定义，支持主键、外键、唯一约束、检查约束等。查询语言是SQL，可以进行多表连接、子查询、窗口函数、聚合统计等复杂操作。例如统计每个部门中薪资超过平均值的员工，一条SQL即可完成。这种表达力是服务端复杂业务的重要支撑。
CREATE TABLE employees (
id SERIAL PRIMARY KEY,
department_id INT NOT NULL,
name TEXT NOT NULL,
salary NUMERIC(10,2) NOT NULL
);
SELECT d.name, COUNT(*) AS high_earners
FROM employees e
JOIN departments d ON d.id = e.department_id
WHERE e.salary > (
SELECT AVG(salary) FROM employees
WHERE department_id = e.department_id
)
GROUP BY d.name;
Realm使用对象模型，开发者定义继承自RealmObject的类，属性直接映射为存储字段。关系通过RealmList表示，支持到一和到多。查询使用链式API，例如在Swift中通过NSPredicate或Realm Swift查询构建器过滤对象。相比SQL，Realm的查询能力更适合单表或简单关联，复杂聚合和跨表分析能力较弱。
import RealmSwift
class Dog: Object {
@Persisted var name: String
@Persisted var age: Int
}
class Person: Object {
@Persisted var name: String
@Persisted var dogs: List<Dog>
}
let realm = try! Realm()
let puppies = realm.objects(Dog.self).filter("age < 3")
let sortedPuppies = puppies.sorted(byKeyPath: "name")
从数据演进角度看，PostgreSQL可以通过ALTER TABLE在线调整结构，配合迁移工具做版本化变更。Realm的模式迁移需要定义SchemaVersion和迁移逻辑，虽然也能处理属性增加、删除、重命名，但对复杂结构变更的灵活性不如SQL数据库。如果应用需要频繁调整本地数据结构，要在开发阶段预留迁移策略。
性能特性与资源占用
PostgreSQL的性能取决于服务器硬件、索引设计、查询计划和并发压力。它通过共享缓冲池、WAL日志、并发控制等手段处理高并发写入和复杂查询。对于移动客户端来说，直接访问远程PostgreSQL会引入网络延迟，通常需要配合Redis等缓存或CDN降低响应时间。但如果后端API设计合理，PostgreSQL可以稳定支撑每秒数千级别的读写。
Realm的设计目标是移动设备上的低延迟和低内存占用。它使用内存映射文件，对象访问接近内存速度，写入通过写时复制和事务日志保证原子性。在典型移动设备上，打开一个包含数万条记录的Realm数据库并执行过滤，通常可以在几十毫秒内完成。资源占用方面，Realm的库体积约为几MB，具体大小随平台和版本略有差异。不过Realm默认会将数据加载进地址空间，对超大表或超大字段需要谨慎评估。
这里有一个常见误区：把Realm当作移动端的完整关系数据库来存储所有业务数据。移动设备存储空间和内存有限，Realm适合保存用户资料、会话缓存、草稿、最近浏览等中小规模数据。如果需要离线保存百万级记录并做复杂报表，建议把原始数据同步到服务端PostgreSQL再进行分析，移动端只保留摘要或分页数据。
离线能力与同步策略
PostgreSQL本身不直接提供移动端离线同步方案。移动应用要支持离线写入，通常需要自定义同步层，例如客户端先把变更记录到本地队列，联网后通过API推送到服务端。这种模式需要处理冲突合并、幂等重试、顺序一致性和断点续传，实现复杂度不低。PostgreSQL可以配合逻辑复制、触发器和审计表记录变更，但同步协议仍需应用层实现。
Realm在离线读写方面天然占优。所有查询和写入都在本地完成，不依赖网络状态。开发者可以在完全离线的情况下正常使用应用，待网络恢复后再执行同步。Realm Platform或Atlas Device Sync等商业化方案提供设备与服务端之间的增量同步，支持冲突解决策略。需要注意的是，这些同步服务在服务端通常仍由MongoDB或其他数据库承载，而不是直接对接PostgreSQL。如果团队希望保持PostgreSQL作为唯一服务端存储，往往要自己实现Realm到PostgreSQL的同步管道。
对于离线优先的移动应用，推荐架构是：移动端使用Realm作为读写缓存，服务端使用PostgreSQL作为权威数据库，中间通过REST或GraphQL API传递变更。客户端可以记录操作日志，通过上次同步版本号拉取增量数据。这种混合架构兼顾离线体验和数据一致性。
选型思路：单独使用还是混合部署
判断是否使用Realm，关键看移动端是否有独立的离线读写需求。如果应用只在有网状态下使用，所有数据都在服务端处理，移动端只负责展示，那么使用轻量级缓存如SQLite或Realm都可以，甚至可以不引入本地数据库。如果应用需要在弱网、飞行模式或地下车库等无网环境正常编辑数据，Realm会显著提升开发效率。
判断是否使用PostgreSQL，通常不取决于移动端，而取决于服务端对事务、关联查询、权限管理和生态工具的要求。PostgreSQL拥有成熟的扩展体系，例如PostGIS处理地理数据，TimescaleDB处理时序数据，以及丰富的监控和备份工具。如果团队已有PostgreSQL运维经验，继续使用它作为主存储是低风险选择。
实际项目中，二者更多是协同关系。例如一个任务管理应用，移动端用Realm保存任务草稿和本地状态，用户新建任务后立即写入Realm并更新界面，后台同步服务把变更推送到PostgreSQL。服务端在PostgreSQL上做权限校验、生成统计报表、向其他协作者推送通知。这样既能保证离线可用，又能利用PostgreSQL的强一致性和复杂查询能力。
最后提醒，不要因为某个数据库热门就强行引入。移动端引入Realm会增加包体积和迁移维护成本，服务端引入PostgreSQL则涉及部署和运维。先明确数据读写路径、离线要求、并发规模、团队技术栈，再决定每个环节使用哪种数据库。
PostgreSQLRealm移动数据库修改时间：2026-08-25 00:14:11