LanceDB工程师Weston Pace：表格式的核心分歧不在数据文件，而在并发写入的协调机制
表格式存在的根本原因是数据会变而文件不会变，因此所有变更都表达为创建新文件。这带来一个关键问题：多个写入者同时提交时，谁的新文件集成为'当前版本'？Weston Pace指出，这个原子协调机制的选择——依赖文件系统put-if-not-exists的零基础设施方案，还是依赖外部服务的集中式方案——对表格式的性能和复杂度有深远影响，且没有通用解。
文件一旦写入就基本不可变，而数据天然需要变更。行要修正，新观测要记录，旧记录要删除。这个矛盾是表格式存在的唯一理由：既然不能修改文件，就用创建新文件来表达变更。追加一行写一个新文件，删除一行写一个标记文件，压缩数据写一批新文件，甚至获取和释放表锁也是新文件。代价是，同一张表在任意时刻对应着多个文件，其中一些不是数据文件而是删除标记或索引。于是必须有人写下一套规则，说明哪些文件当前有效、各自扮演什么角色。
规则本身不难写。真正困难的是：当两个写入者同时想提交各自的新文件集时，如何让其中一个成为'当前版本'而另一个失败？Weston Pace把这个问题称为表格式的'原子内核'，并指出所有表格式——无论叫timeline、catalog还是其他名字——最终都依赖某个同步并发写入者的机制。这个机制的选择对表格式的性能和复杂度有深远影响，而且它把设计空间清晰地分成两类。
第一类是零基础设施原子操作。几乎所有云存储都提供put-if-not-exists语义，传统文件系统则普遍支持rename-if-not-exists。利用这些原语，可以在不部署任何额外服务的情况下构建版本序列：写入者尝试原子性地创建下一个版本号的元数据文件，成功者胜出，失败者重试。好处显而易见——五十台EC2实例可以同时向S3上的同一张表发布数据，不需要任何协调服务。但作者给出了一个具体的性能上限：截至他写作时，云存储的put-if-not-exists大约限制在每秒十次提交左右。对于高频小写入场景，这会成为瓶颈。
第二类是集中式协调。DuckLake用Postgres实例作为提交协调器，内部通过互斥锁或CAS原语同步写入者。Iceberg的REST catalog也属于这一类。这种方式有可能带来更高的事务速率（作者自己也指出这一点并不确定），且能适用于所有文件系统——包括那些不支持put-if-not-exists或POSIX rename的非主流文件系统。代价是需要维护一个长期运行的服务，增加了运维负担和故障面。
两类方案并非优劣关系，而是适用场景不同。读多写少的表用零基础设施足够；高频小写入的表可能需要集中式协调；批量大写入的表两者都行。Lance默认使用零基础设施但允许扩展为集中式；Iceberg标准路径是REST协调但也提供零基础设施的boring catalog。作者的结论是：表格式面对大量细微技术决策，每个决策都偏向某一类工作负载，最好的做法往往是实现多种路径并用启发式自动选择，而不是让用户面对配置噩梦。