一个库开始生长时，增加能力通常比删去能力更自然。

Pytuck 从一个纯 Python 的单文件数据库出发，逐渐拥有 JSON、CSV、SQLite、DuckDB、Excel 与 XML 等后端。多种格式让同一套模型可以抵达更多场景，也让核心代码必须同时照看更多语义：哪些能力可以下推，哪些数据需要转换，不同引擎的事务、分页和类型又该如何对齐。

但有些使用者从始至终只需要一件事：在受限 Python 环境里，可靠地读写一个 .pytuck 文件。

Pytucky 就是把这条路径单独留下来的尝试。

减法不是简化命名

Pytucky 从 Pytuck 的核心 API 分化而来，只保留 PTK7 单文件引擎。它仍然是纯 Python、默认零第三方运行时依赖，也仍然提供 Column、声明式模型、Session、Relationship 和 select()、insert()、update()、delete() 等接口。

多数基础用法甚至只需要更换导入位置：

from pytucky import (
    Column,
    PureBaseModel,
    Session,
    Storage,
    declarative_base,
    insert,
    select,
)

db = Storage("archive.pytuck")
Base: type[PureBaseModel] = declarative_base(db)


class Entry(Base):
    __tablename__ = "entries"

    id = Column(int, primary_key=True)
    title = Column(str, nullable=False, index=True)


session = Session(db)
session.execute(insert(Entry).values(title="A fixed star"))
session.commit()

entry = session.execute(
    select(Entry).where(Entry.title == "A fixed star")
).first()

db.flush()
db.close()

减去多后端之后，Storage 不再需要选择引擎，也不需要维护一套插件注册与可选依赖边界。代码可以把更多注意力放在 PTK7 本身：文件怎样打开，记录怎样定位，索引何时物化，变更怎样安全地再次写回同一个文件。

它不是把 Pytuck 换一个名字重新发布，也不是为了证明“功能少就一定更快”。在相同数据与流程下，两者的实际性能十分接近，某些操作各有高低。Pytucky 真正购买到的是更窄的实现面：当问题出现时，需要追踪的路径只有一条。

与 Pytuck 共享同一种文件语言

Pytucky 与 Pytuck 共享 PTK7 格式。一个库写出的 .pytuck 文件可以由另一个库打开、修改再写回；无加密以及 low、medium、high 四种加密等级都经过双向兼容验证。

这种兼容关系很重要。它让 Pytucky 不必建立一座与原项目隔绝的小岛：应用可以在受限环境中只携带更专注的 Pytucky，在开发机上仍然用 Pytuck 的多后端能力进行检查、迁移，或交给 Pytuck View 直接查看。

兼容也意味着约束。格式演进不能只考虑一个仓库内部是否能读写成功，还要确认另一个实现是否仍能理解相同的表结构、索引、加密与记录编码。这里的独立，是实现可以分别演进；不是文件语言可以随意分叉。

把读取推迟到真正需要时

重新打开 PTK7 文件时，Pytucky 先读取目录、Schema 与索引元数据，不立即把所有记录解码进内存。主键可以通过保存的偏移直接定位记录；普通索引在第一次使用时物化，后续查询复用缓存。

写回文件也围绕同一原则工作。一次 flush 会先找出真正改变的表：未修改的表可以直接沿用原有编码块，修改过的表则根据新增、更新和删除形成覆盖层，再重新组织需要变化的部分。这样做并没有把单文件变成日志型数据库，但避免了“只改一张表，却先解码全部表”的无谓工作。

因为核心只有一个后端，这些优化不需要同时迁就 JSON 的可读性、CSV 的空值语义或 SQL 引擎的执行方式。懒加载、主键直达、索引和增量 flush 可以围绕同一份格式共同设计。

专注也有清楚的边界

如果项目需要在人类可读的 JSON、办公使用的 Excel、原生 SQLite 或分析型 DuckDB 之间切换，Pytuck 仍然是更合适的入口。如果只需要一个纯 Python、单进程、本地嵌入式的 PTK7 文件，并希望依赖面与实现面都尽量收紧，Pytucky 才真正体现价值。

它仍不适合高并发服务、复杂 SQL 联表和超大数据集，也不会因为只剩一个引擎就突然跨过纯 Python 的性能边界。它解决的不是数据库世界的一般问题，而是 Pytuck 最初那道更窄的题：当环境不完整时，怎样让结构化数据仍有一个可靠的容身之处。

写下这篇文章时，Pytucky 的公开版本为 1.2.0。对我而言，它更像同一家族中一次持续进行的减法实验——看看当多余的岔路被移走之后，一条单文件路径究竟可以被打磨得多清楚。

• GitHub 仓库
• PyPI
• 中文文档