支持很多数据库，但没有主路径
很多 starter 会罗列引擎，却不告诉你哪条实现路线才是真正 production-ready。
Stack / Database Integration
不是只搭一遍 schema，而是为持续产品演进设计的数据层
BunShip 通过 Postgres 与 Drizzle 组织 schema、migrations 与 typed data access，让 auth、billing、AI workflow 等模块围绕同一数据契约演进。
- Postgres + Drizzle 是主路径
- migrations 与 seeds 已有文档支持
- typed data access 可复用
- 支撑 auth、billing、AI 状态管理
Typed
Data access
Drizzle 让 schema 与 query 行为保持更紧密。
1
主数据库路径
与其早早拆很多数据库页，不如先把主实现路径讲清楚。
Shared
Package model
数据库能力可被整个 workspace 复用，而不是散在各路由里。
这个页面应该解释数据库策略，而不是过早拆成很多低价值引擎页。
这个页面应该解释数据库策略，而不是过早拆成很多低价值引擎页。
Schema ownershipMigrationsSeedsTyped queries
这个页面要解决什么问题
技术买家真正想确认的是数据层是否清晰稳定，而不是看一串数据库名称列表。
schema 逻辑散落各处
如果没有稳定数据层，auth、billing、AI 模块都会更难安全演进。
migrations 被当成附属品
买家需要知道 schema 变更与部署流程已经被考虑进去。
What's included
围绕 BunShip 已经实现的主数据库路径来讲，而不是分散注意力。
Drizzle schema / migration model
schema ownership 与 migrations 已是产品基础的一部分。
Shared typed access layer
数据库访问可被多个模块复用，而不是复制到 feature code 中。
Seed 与环境工作流
初始化与环境差异已经在仓库叙事里出现。
Why it matters
这页用于提升技术信任度，并减少“数据库到底怎么落地”的不确定性。
更安全地演进产品
auth、billing、AI 等模块能围绕清晰的数据契约扩展。
减少实现歧义
买家能看清主路径，而不是面对多个半支持选项。
更符合生产工作流
schema changes、seeds 与 deployment concerns 已被纳入系统设计。
Implementation notes
更深的技术细节交给 docs，这页保留 architecture 层信息。
Who it's for
适合技术评估者与打算长期维护产品的团队。
工程负责人
评估 schema 与 query 模型是否适合产品增长。
关注合规与核心数据的创始人
看清 customer、billing、usage 数据落在哪里。
Agency 团队
以一条强默认路径为基础，而不是每个客户都重造数据层。
FAQ
避免 database messaging 过早碎片化成很多 support matrix 页。
Next step
先建立技术信心，再进入 docs 或更商业化模块
继续看 database docs，或者回到 billing 这种直接依赖数据层的功能页。