从 OrbStack 迁移到 Apple Container，并带上 PostgreSQL
内容提要
作者将 Mac 上的 OrbStack 迁移到 Apple Container，仅保留 PostgreSQL。迁移前发现 compose 挂载路径与实际 PGDATA 不符，先做了逻辑与物理备份。随后用 Apple Container 加载镜像并启动，通过命令行参数关闭归档模式，并用 LaunchAgent 实现自启。卸载 OrbStack 后释放约 19GiB 空间，数据库正常运行。
延伸解读
迁移前必须核实实际挂载路径
作者发现 compose 文件挂载的 ./pg17 目录实际为空，而数据库真实位于容器内 /data/data。若直接停止 OrbStack 并复用原挂载路径，将导致数据丢失。这提醒我们：不要轻信 compose 中的 volume 配置，应通过 docker inspect 确认运行容器的 PGDATA 和挂载点，再制定迁移方案。
区分必要 WAL 与归档 WAL 以控制空间
物理备份中 /data/backup/wal 占用 6.8G，而实际表数据仅几百 MB。作者指出，这是镜像将 WAL 归档到本地所致，并非业务数据膨胀。迁移时通过命令行参数关闭 archive_mode，可避免归档 WAL 持续增长。但 wal_level=logical 被保留，因为随意关闭可能影响逻辑复制或扩展。
Apple Container 自启动需额外配置
Apple Container 目前没有类似 Docker Compose 的 restart: unless-stopped 机制。brew services start container 仅启动 apiserver，不保证特定容器自启。作者通过用户 LaunchAgent 运行脚本，先启动 container system，再检查并启动 scriber_pg 容器，实现了开机自启。
迁移收益与资源占用对比
卸载 OrbStack 并清理残留后，共释放约 19GiB 空间。迁移后 Apple Container 运行时数据占 3.8G，新 PostgreSQL 数据目录仅 274M，scriber_pg 实际内存约 148MiB，CPU 几乎为零。对于仅运行 PostgreSQL 的 Mac 而言，减少一个常驻运行时是合理的轻量化选择。
Q&A
为什么作者要从 OrbStack 迁移到 Apple Container？
因为作者在 Mac 上唯一长期运行的本地服务是 PostgreSQL，依赖面很小，而 Apple 的容器 CLI 现在可以运行 Linux 容器，所以为了缩小运行时环境，决定迁移。
迁移前发现了什么关键问题？
docker-compose.yml 中挂载的 ./pg17 目录实际是空的，因为镜像使用的 PGDATA 是 /data/data，真正的数据库数据在旧容器的 /data 下，而不是主机挂载的目录。
作者做了哪些备份？
做了逻辑备份和物理备份：逻辑备份用 pg_dumpall 导出并 gzip 压缩，只有 38M；物理备份用 tar 打包 /data 目录并用 zstd 压缩，大小为 6.8G。
为什么物理备份有 6.8G 而逻辑备份只有 38M？
因为 /data 目录下大部分是镜像自身的本地 WAL 归档（约 6.8G），实际表数据只有几百 MB，逻辑备份只包含数据库内容，所以小很多。
如何让 PostgreSQL 在 Apple Container 中启动时关闭归档模式？
在 container run 命令的最后加上 postgres -c archive_mode=off -c archive_command=，通过命令行参数覆盖配置，因为镜像启动时会重写 postgresql.conf，直接改文件会被覆盖。
如何实现 PostgreSQL 容器在 Apple Container 中自启动？
创建一个用户 LaunchAgent plist 文件，运行一个脚本：先执行 container system start，然后检查容器是否在运行，如果不在则执行 container start scriber_pg。
迁移后释放了多少磁盘空间？
总共释放了约 19GiB 空间，包括删除物理回滚归档后的 14GiB 和卸载 OrbStack 后的 26GiB（从最紧张时的 6.8GiB 算起）。
迁移后 PostgreSQL 容器的资源占用情况如何？
实际内存约 148MiB（限制 4GiB），CPU 占用 0.00%，新的 PostgreSQL 数据目录只有 274M。
