Metapi 数据库架构解析SQLite、MySQL、PostgreSQL 三库兼容的 Drizzle ORM 设计【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点 汇聚成 一个 API Key、一个入口自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/gh_mirrors/meta/metapiMetapi 是一款把 New API、One API、OneHub、DoneHub、Veloera、AnyRouter、Sub2API 等上游站点汇聚成一个 API Key、一个入口的 AI 模型路由网关它自动发现模型、智能路由、追求成本最优。而这一切的背后是一套真正支持 SQLite、MySQL、PostgreSQL 三种数据库的架构设计——同一份表结构定义既能零配置跑在本地单文件里也能平滑迁移到云端数据库。本文带你完整读懂 Metapi 数据库架构的设计思路。一张数据地图Metapi 存了什么在谈兼容之前先看 Metapi 到底存哪些数据。所有核心表都定义在 src/server/db/schema.ts 中可以按功能分为四组数据组核心表存储内容站点与账号sites、accounts、account_tokens站点平台new-api / one-api / sub2api…、账号令牌、余额与权重路由与调度token_routes、route_channels、oauth_route_units模型匹配规则、渠道优先级/权重、连续失败与冷却状态日志与调试proxy_logs、proxy_debug_traces、proxy_debug_attempts每次代理调用的 Token 消耗、成本、延迟、重试明细用量与运营site_day_usage、model_day_usage、downstream_api_keys按天/按小时聚合的用量统计、下游 Key 额度控制举个直观的例子你调用一次模型proxy_logs表就会落一条记录包含请求模型与实际模型、提示词/补全 Token 数、估算成本、首字节延迟等信息仪表盘上的花费曲线、渠道成功率都是对这些表的查询结果。单一事实来源Drizzle ORM 一次定义处处生成Metapi 数据库架构最值得学的一点是只维护一份 Schema。在 src/server/db/schema.ts 中所有表都用 Drizzle ORM 的声明式 API 描述例如站点表定义了platform、global_weight、custom_headers等字段并附带组合索引export const sites sqliteTable(sites, { id: integer(id).primaryKey({ autoIncrement: true }), name: text(name).notNull(), platform: text(platform).notNull(), globalWeight: real(global_weight).default(1), // ... }, (table) ({ platformUrlUnique: uniqueIndex(sites_platform_url_unique).on(table.platform, table.url), }));这份定义是整个数据库架构的唯一事实来源由 drizzle.config.ts 驱动 drizzle-kit以 SQLite 为基准方言生成迁移 SQL存放在 drizzle/ 目录目前有 0000 到 0027 共 28 个迁移文件同时通过 src/server/db/schemaContract.ts 输出 schemaContract.json 契约文件让 MySQL / PostgreSQL 的生成产物可以与这份契约自动比对防止三库漂移src/server/db/generated/ 目录下则预生成了mysql.bootstrap.sql、postgres.bootstrap.sql等建库脚本字段、类型、索引与 SQLite 版本一一对应。三套引擎一套接口连接层如何统一对上层业务代码来说现在跑的是哪种数据库几乎是无感的。核心逻辑在 src/server/db/index.ts启动时按方言装配驱动SQLite 使用better-sqlite3直连本地文件MySQL 通过mysql2连接池、PostgreSQL 通过pg连接池并支持DB_SSL开启加密连接。用 Drizzle 的 proxy 适配器抹平差异三种驱动分别接入drizzle-orm/sqlite-proxy、mysql-proxy、pg-proxy再统一套上 src/server/db/schema.ts 中的表定义。业务层写的查询语句完全一致方言差异在连接层被消化掉。补齐方言差异PostgreSQL 插入后需要RETURNING id才能拿到自增主键、布尔值在 SQLite 中是整数等细节都由该层统一适配包括 postgresJsonTextParsers.ts 这类针对 JSON 字段的解析器。这种薄适配层 声明式 Schema的组合是 Metapi 数据库架构能够三库兼容的关键。自动迁移与兼容补丁升级不操心数据库架构的另一半价值在演进。Metapi 对三套数据库采用了分工不同的升级策略SQLite正式迁移流水线。启动时由 src/server/db/migrate.ts 依次执行 drizzle/ 下的迁移 SQL并带有迁移校验标记VERIFIED_SCHEMA_MARKERS与重复列冲突的自动恢复重试机制老库升级到新版无需手工干预。MySQL / PostgreSQL运行时 Bootstrap。启动时由 src/server/db/runtimeSchemaBootstrap.ts 执行预生成的 bootstrap 脚本一次性建齐表与索引。三库共用的兼容补丁层。对于运行中老库缺少的列src/server/db/index.ts 提供了一组ensure...Column()函数——先探测表和列是否存在SQLite 查sqlite_masterMySQL/PostgreSQL 查information_schema缺失时按方言生成对应的ALTER TABLE语句并容忍重复列错误。例如为proxy_logs补billing_details、client_family等列时就是三库各生成一份 DDL 再统一执行。这套机制意味着无论你从哪个旧版本升级、用哪种数据库重启即完成结构对齐。类型映射JSON 字段如何三库通用一个容易踩坑的细节是 JSON 字段。在 src/server/db/schema.ts 中像custom_headers、model_mapping、billing_details这类结构化数据统一声明为textSQLite直接存 JSON 字符串MySQLbootstrap 脚本映射为JSON类型PostgreSQL映射为JSONB类型读写时再经 postgresJsonTextParsers.ts 转回字符串。应用层拿到的永远是同一种JSON 字符串形态方言差异被藏在生成脚本和解析器里业务代码零改动。新手怎么选库30 秒速查表场景推荐需要做什么本地 / 桌面端 / 单机轻量部署SQLite默认什么都不用配数据自动落在DATA_DIR/hub.db已有 MySQL 或云 MySQL如 TiDB、Neon 的 MySQL 兼容库MySQL设置DB_TYPEmysql与DB_URL连接串已有 PostgreSQL 或云 PG如 Supabase、NeonPostgreSQL设置DB_TYPEpostgres与DB_URL连接串DB_TYPEpostgres DB_URLpostgres://user:passwordhost:5432/metapi DB_SSLtrue配置入口详见 docs/configuration.md云端数据库的具体拼接方式可参考 docs/deployment.md。切换数据库类型后重启后端即生效。小结这套架构好在哪一份定义三种落库Schema 只写一次契约文件保证三库结构一致从根源上杜绝改了一边漏了另一边零配置起步按需上云SQLite 开箱即用云端部署只需两个环境变量升级自愈迁移流水线 运行时兼容补丁老库重启即对齐差异下沉自增主键、JSON 类型、布尔表示等方言细节全部收敛在连接适配层业务代码无感。如果你正在设计一个本地优先、可上云的应用数据库Metapi 的 Drizzle ORM 三库兼容方案src/server/db/值得完整读一遍。【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点 汇聚成 一个 API Key、一个入口自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/gh_mirrors/meta/metapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Metapi 数据库架构解析：SQLite、MySQL、PostgreSQL 三库兼容的 Drizzle ORM 设计
Metapi 数据库架构解析SQLite、MySQL、PostgreSQL 三库兼容的 Drizzle ORM 设计【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点 汇聚成 一个 API Key、一个入口自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/gh_mirrors/meta/metapiMetapi 是一款把 New API、One API、OneHub、DoneHub、Veloera、AnyRouter、Sub2API 等上游站点汇聚成一个 API Key、一个入口的 AI 模型路由网关它自动发现模型、智能路由、追求成本最优。而这一切的背后是一套真正支持 SQLite、MySQL、PostgreSQL 三种数据库的架构设计——同一份表结构定义既能零配置跑在本地单文件里也能平滑迁移到云端数据库。本文带你完整读懂 Metapi 数据库架构的设计思路。一张数据地图Metapi 存了什么在谈兼容之前先看 Metapi 到底存哪些数据。所有核心表都定义在 src/server/db/schema.ts 中可以按功能分为四组数据组核心表存储内容站点与账号sites、accounts、account_tokens站点平台new-api / one-api / sub2api…、账号令牌、余额与权重路由与调度token_routes、route_channels、oauth_route_units模型匹配规则、渠道优先级/权重、连续失败与冷却状态日志与调试proxy_logs、proxy_debug_traces、proxy_debug_attempts每次代理调用的 Token 消耗、成本、延迟、重试明细用量与运营site_day_usage、model_day_usage、downstream_api_keys按天/按小时聚合的用量统计、下游 Key 额度控制举个直观的例子你调用一次模型proxy_logs表就会落一条记录包含请求模型与实际模型、提示词/补全 Token 数、估算成本、首字节延迟等信息仪表盘上的花费曲线、渠道成功率都是对这些表的查询结果。单一事实来源Drizzle ORM 一次定义处处生成Metapi 数据库架构最值得学的一点是只维护一份 Schema。在 src/server/db/schema.ts 中所有表都用 Drizzle ORM 的声明式 API 描述例如站点表定义了platform、global_weight、custom_headers等字段并附带组合索引export const sites sqliteTable(sites, { id: integer(id).primaryKey({ autoIncrement: true }), name: text(name).notNull(), platform: text(platform).notNull(), globalWeight: real(global_weight).default(1), // ... }, (table) ({ platformUrlUnique: uniqueIndex(sites_platform_url_unique).on(table.platform, table.url), }));这份定义是整个数据库架构的唯一事实来源由 drizzle.config.ts 驱动 drizzle-kit以 SQLite 为基准方言生成迁移 SQL存放在 drizzle/ 目录目前有 0000 到 0027 共 28 个迁移文件同时通过 src/server/db/schemaContract.ts 输出 schemaContract.json 契约文件让 MySQL / PostgreSQL 的生成产物可以与这份契约自动比对防止三库漂移src/server/db/generated/ 目录下则预生成了mysql.bootstrap.sql、postgres.bootstrap.sql等建库脚本字段、类型、索引与 SQLite 版本一一对应。三套引擎一套接口连接层如何统一对上层业务代码来说现在跑的是哪种数据库几乎是无感的。核心逻辑在 src/server/db/index.ts启动时按方言装配驱动SQLite 使用better-sqlite3直连本地文件MySQL 通过mysql2连接池、PostgreSQL 通过pg连接池并支持DB_SSL开启加密连接。用 Drizzle 的 proxy 适配器抹平差异三种驱动分别接入drizzle-orm/sqlite-proxy、mysql-proxy、pg-proxy再统一套上 src/server/db/schema.ts 中的表定义。业务层写的查询语句完全一致方言差异在连接层被消化掉。补齐方言差异PostgreSQL 插入后需要RETURNING id才能拿到自增主键、布尔值在 SQLite 中是整数等细节都由该层统一适配包括 postgresJsonTextParsers.ts 这类针对 JSON 字段的解析器。这种薄适配层 声明式 Schema的组合是 Metapi 数据库架构能够三库兼容的关键。自动迁移与兼容补丁升级不操心数据库架构的另一半价值在演进。Metapi 对三套数据库采用了分工不同的升级策略SQLite正式迁移流水线。启动时由 src/server/db/migrate.ts 依次执行 drizzle/ 下的迁移 SQL并带有迁移校验标记VERIFIED_SCHEMA_MARKERS与重复列冲突的自动恢复重试机制老库升级到新版无需手工干预。MySQL / PostgreSQL运行时 Bootstrap。启动时由 src/server/db/runtimeSchemaBootstrap.ts 执行预生成的 bootstrap 脚本一次性建齐表与索引。三库共用的兼容补丁层。对于运行中老库缺少的列src/server/db/index.ts 提供了一组ensure...Column()函数——先探测表和列是否存在SQLite 查sqlite_masterMySQL/PostgreSQL 查information_schema缺失时按方言生成对应的ALTER TABLE语句并容忍重复列错误。例如为proxy_logs补billing_details、client_family等列时就是三库各生成一份 DDL 再统一执行。这套机制意味着无论你从哪个旧版本升级、用哪种数据库重启即完成结构对齐。类型映射JSON 字段如何三库通用一个容易踩坑的细节是 JSON 字段。在 src/server/db/schema.ts 中像custom_headers、model_mapping、billing_details这类结构化数据统一声明为textSQLite直接存 JSON 字符串MySQLbootstrap 脚本映射为JSON类型PostgreSQL映射为JSONB类型读写时再经 postgresJsonTextParsers.ts 转回字符串。应用层拿到的永远是同一种JSON 字符串形态方言差异被藏在生成脚本和解析器里业务代码零改动。新手怎么选库30 秒速查表场景推荐需要做什么本地 / 桌面端 / 单机轻量部署SQLite默认什么都不用配数据自动落在DATA_DIR/hub.db已有 MySQL 或云 MySQL如 TiDB、Neon 的 MySQL 兼容库MySQL设置DB_TYPEmysql与DB_URL连接串已有 PostgreSQL 或云 PG如 Supabase、NeonPostgreSQL设置DB_TYPEpostgres与DB_URL连接串DB_TYPEpostgres DB_URLpostgres://user:passwordhost:5432/metapi DB_SSLtrue配置入口详见 docs/configuration.md云端数据库的具体拼接方式可参考 docs/deployment.md。切换数据库类型后重启后端即生效。小结这套架构好在哪一份定义三种落库Schema 只写一次契约文件保证三库结构一致从根源上杜绝改了一边漏了另一边零配置起步按需上云SQLite 开箱即用云端部署只需两个环境变量升级自愈迁移流水线 运行时兼容补丁老库重启即对齐差异下沉自增主键、JSON 类型、布尔表示等方言细节全部收敛在连接适配层业务代码无感。如果你正在设计一个本地优先、可上云的应用数据库Metapi 的 Drizzle ORM 三库兼容方案src/server/db/值得完整读一遍。【免费下载链接】metapi把你在各处注册的 New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API 等站点 汇聚成 一个 API Key、一个入口自动发现模型、智能路由、成本最优项目地址: https://gitcode.com/gh_mirrors/meta/metapi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考