看到有人直接把这句英文当项目标题发出来Show HN: PopSQL and SeekWell were shutting down, so I built the replacement。按作者自己的描述团队平时依赖的两类服务先后要停止运行——一类是多人一起写 SQL、保存查询和分享结果的协作编辑器另一类是定时执行 SQL、把结果同步到表格和通知渠道的自动化工具。与其再次把团队知识迁移到另一个 SaaS 上赌它不会停他选择自己重建一个替代品。这个题目值得拆开看的不是“我又做了一个新工具”而是一个很典型的数据团队自救场景。PopSQL 和 SeekWell 停不停服、具体哪天停不同渠道的说法不一定一致但这类工具一旦下线真正留在平台里的资产——连接配置、查询历史、调度计划、下游依赖——不会自动转移到新平台。如果你也在维护内部 SQL 工具或者团队大量依赖某个外部平台保存查询、定时取数那么这篇文章的思路可以直接拿来做一次自查。下面按实际落地顺序拆解先搞清楚这类工具到底解决了什么问题再谈怎么盘点现状然后是四个模块的最小自建方案最后是迁移和排错顺序。1. 先看清 PopSQL 和 SeekWell 在一条链路的哪一端1.1 一个偏“人和查询”一个偏“查询和机器”很多人容易把 PopSQL 和 SeekWell 当成同类产品其实它们在数据工作流里处在不同位置。PopSQL 代表的是“团队协同写 SQL”。在它出现前分析师们最常见的协作方式是每个人本地连数据库把常用 SQL 存在自己电脑里或者贴到某个文档里。换人、换机器、换数据库账号查询就散架了。这类工具解决的是把 SQL 变成团队资产能命名、能搜索、能分享甚至能基于同一份数据讨论口径。SeekWell 代表的则是“让 SQL 自动跑起来”。它不关心你写 SQL 时界面好不好看它关心的是有没有一条查询每天定时执行结果能不能自动同步到指定表格出错了是否有人知道这种能力本质上是一个定时数据管道只是入口是一条 SQL 而已。真实团队里这两件事通常是连着的。分析师在白天把一条取数 SQL 改好晚上这条 SQL 定时执行结果自动送到运营表格里。如果一个负责“大家一起写”另一个负责“写完之后自动跑”那它们同时停服的影响就不是丢掉一个编辑框而是整条取数链路断掉。这里我不讨论具体产品停服时间也不做具体产品评测。我更想表达的判断是你看到的标题是在讲一个“替代品”但替代的不只是界面而是一整条从连接、查询、调度到结果投递的链路。1.2 工具下线后真正丢的是这五类资产如果团队只是偶尔打开工具看一眼数据停服影响确实不大。但 PopSQL 和 SeekWell 这类工具一旦被深度使用平台里积累的资产会被低估连接配置。内网数据库地址、只读账号、端口、SSL 参数、默认 schema这些东西通常不会完整保存在个人电脑里很多人是“打开工具就能跑”并不记得底层参数。查询资产。保存过的 SQL、注释、参数、表名缩写、业务口径说明。每一条能稳定跑到现在的 SQL背后都经历过排错不是一串普通字符串。调度计划。什么时候跑、用哪个时区、失败要不要重试、结果发到哪里。这部分最容易在迁移时被漏掉因为它是后台运行的平时没人注意。结果投递关系。哪个表格依赖这个查询更新、哪个通知群每天要收一份数据摘要断掉一两天未必有人立刻发现但业务方一定会先发现问题。权限和审计痕迹。谁执行过敏感查询、谁改过任务、谁把结果导出过。小团队未必需要完整审计系统但“谁动了这条 SQL”这个信息不该完全没有记录。你可能觉得这些东西靠复制粘贴就能抢救但批量复制时大概率会漏掉时区、参数、下游格式这些细节。自建替代品时最忌讳的也是“做一个好看的查询页面”而把调度、投递、日志这些后台能力放到最后。2. 写第一行代码之前先把功能现状盘成一张表2.1 盘点范围连接、查询、调度、下游很多人看完标题会直接进入“选什么技术栈”阶段这是容易走偏的地方。自建替代品这件事真正的约束不在代码而在现状盘点。你可以按下面四层把现有依赖摸一遍连接层团队现在连了哪些数据库分别是哪些引擎是测试库还是生产库副本账号权限是否都是只读连接信息之前谁在维护查询层哪些 SQL 是高频操作哪些只是个人临时查询哪些 SQL 已经变成每天、每周固定跑的“事实标准”它们依赖哪些参数调度层现有定时任务有多少个分布在几个平台有没有重叠跑挂之后的发现机制是什么是靠人发现还是靠工具报警投递层查询结果最后流向哪里是表格、离线文件、看板还是聊天机器人下游对格式有没有硬性要求这一步不需要写代码最好的产出是一张表格。每一条记录都对应一个真实使用者后面做替代品时这些记录就是验收用例。2.2 把功能分成“没有会卡死”和“有了才优雅”盘点结束后不要急着把所有功能都做出来。我一般会把功能分成三类。第一类是“没有会卡死”的基础能力能新建连接、能保存查询、能执行查询、能看到结果、能查看日志、能按计划跑一次、失败时能被发现。这套闭环之外再花哨的功能都先放一边。第二类是“有了会很舒服”的增强能力多人评论、查询目录分组、带参数模板、结果版本对比、定时任务历史回放。这些能提升体验但不是替代品上线第一周必须完成的。第三类是“第一阶段最好别碰”的复杂能力复杂 BI 图表、多租户权限体系、细粒度行列权限、可视化拖拽建模。不是说这些没用而是它们会迅速吃掉时间让你迟迟交付不了最核心的“跑 SQL”闭环。可以用一个简单的分类表来辅助决策功能方向第一判断第一阶段要不要做连接管理没有它连查询都发不出去必须做保存查询 / 修改历史查询资产都在这里必须做手动执行并预览结果是日常分析入口必须做定时执行是自动化的核心最小可用版本就要有失败通知没它跑挂了没人知道至少有一条通知链路结果导出 / 同步表格看下游习惯先做 CSV 与固定目标多人协同 / 评论体验加分项可以后置看板图表功能边界大不建议第一版做这个分类还有一个附带价值它可以反向帮你看清现有工具里哪些能力你其实从来没用过。很多团队在迁移时默认“原工具有的功能新工具都要有”结果就是为一个没人用的高级功能付出大量开发成本。3. 最小可用替代品按四个模块先搭起来3.1 第一层连接与凭据这一层解决的是“查询到底跑到哪个数据库上”。无论你用什么语言实现连接信息都不应该硬编码在代码里也不应该存成明文配置文件。数据库账号方面强烈建议先用只读账号。大多数写 SQL 查询的场景只需要 SELECT 权限账号设成只读能挡掉一大半误操作和生产安全事故。以 PostgreSQL 为例最小配置可以长这样-- 示例为替代品创建只读账号不要在生产库上使用高权限账号 CREATE ROLE query_app LOGIN PASSWORD 这里放复杂密码; GRANT CONNECT ON DATABASE analytics TO query_app; GRANT USAGE ON SCHEMA public TO query_app; GRANT SELECT ON ALL TABLES IN SCHEMA public TO query_app; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO query_app;连接配置建议走环境变量或专门的密钥管理服务。下面这个 JSON 只是演示配置结构不要把真实密码塞进去{ connection_id: analytics_main, engine: postgres, host: db.internal.example, port: 5432, database: analytics, schema: public, username: query_app, read_only: true }我习惯把密码单独放在环境变量里代码里只保留连接 ID 和数据库地址。这个习惯在刚起步时看着多了一步但在后续排查权限问题时能省很多事。3.2 第二层查询与参数查询模块的核心不是做一个“好看的编辑器”而是把一条 SQL 的结构化信息存下来。至少要能记录这条查询属于哪个连接、标题是什么、SQL 正文是什么、有没有参数、谁创建的、最近一次运行状态是什么。一条查询记录的基本结构可以是这样{ query_id: q_dau, title: 每日活跃用户数, connection_id: analytics_main, sql: SELECT stat_date, COUNT(DISTINCT user_id) AS dau FROM user_events WHERE stat_date :date GROUP BY stat_date, params: { date: 2025-01-01 }, owner: analyst_a, created_at: 2025-01-01T10:00:00Z }把查询存成结构化字段而不是塞成一段纯文本是为了后面做参数替换和日志记录。执行查询时服务端要做的核心流程是校验连接可用替换参数设置超时和行数上限执行 SQL返回前 N 行预览记录耗时和错误信息。第一次运行先不要做任何花哨功能。能输入 SQL能带参数能跑出结果能展示行数这个模块就算过关了。3.3 第三层调度与日志调度模块是自建替代品里最容易低估的部分。很多人以为用系统自带的 cron 就能解决但对一组定时 SQL 来说你需要的不只是“到点执行”还需要记录每次运行的开始时间、结束时间、状态、错误信息和输出位置。一个可落地的调度任务配置可以这样设计{ schedule_id: s_dau_daily, query_id: q_dau, cron: 0 9 * * *, timezone: Asia/Shanghai, enabled: true, retry_count: 2, timeout_seconds: 120, notification_target: ops_channel }调度器要关注的三个关键点是到点执行并且日志可查失败后按规则重试重试仍然失败时告警不要让同一个任务在上一轮还没结束时又启动新一轮。前两点好理解第三点容易忽略。有些 SQL 跑得慢如果调度周期比查询耗时还短任务就会重叠。结果就是数据库压力翻倍日志里全是相互干扰的记录。最小实现里可以先做“任务执行中不允许再次启动”等任务量大了再考虑队列。3.4 第四层结果落盘与下游通知这一层解决的是“跑完之后结果送到哪里”。查询结果最好的中间形态是标准 CSV 或带结构的结果集然后按目标决定输出方式。团队常见的目标有三类固定文件目录每次运行生成带任务 ID 和时间戳的文件避免覆盖表格类下游通过表格服务提供的 API 写入或者生成 CSV 后人工校验通知渠道把运行结果摘要或错误信息通过 Webhook 发到团队管理工具。第一版不建议做“通用连接器”把每个下游都接一遍。更稳妥的做法是先挑团队最依赖的一到两个目标。比如日常运营主要看表格那就先解决“结果写入表格”如果团队习惯在群里收消息那就先做通知转发。做多了之后你会发现大量时间不是花在写 SQL 工具上而是花在调各种下游接口的格式和鉴权上。4. 系统能跑之后用什么参数和指标判断“真的能用了”4.1 每个模块都要有验收标准很多自建项目的问题是“代码能启动但没人知道算不算成功”。所以每个模块都应该有对应的验收标准模块验收标准复验方式连接能连上库错误信息可读故意填错密码或地址看报错能否定位问题查询能执行 SQL能展示行数和耗时先用一条三秒内能跑完的查询验证参数能正确替换查询参数把时间参数换成昨天和前天对比结果调度到点执行日志完整设置每分钟执行一次的最小任务观察三轮失败重试失败后按规则重试并通知临时停掉目标库或改错连接等待重试和告警结果投递下游文件格式和内容正确用同一份 SQL 在源工具和新工具分别跑对比结果这套标准看起来基础但它能避免一个很常见的返工页面做得很完整真正跑生产计划时才发现时区不对、重试策略缺失、失败没人通知。4.2 几个必定的参数不要用默认值硬扛自建 SQL 工具时会遇到几个参数建议提前定下来查询超时时间。推荐先设 30 秒到 5 分钟具体取决于你的库和查询复杂度不要允许无限制执行。预览行数上限。页面上直接跑查询默认返回前 1000 行即可需要全量导出时再走导出流程。并发执行数。如果只有几个人用先不要开太高并发1 到 3 个并发执行足够启动。重试次数。建议 1 到 3 次并且重试之间要间隔不要连续无限重试。日志保留天数。建议保留 30 天以上便于排查“三天前为什么没更新”。调度时区。必须显式指定不能依赖服务器系统时区否则不同机器部署结果会不一致。这些参数的初始值不一定要最优但要能改、能查、能解释。比参数难调更麻烦的是某个参数不知道是谁改的也不知道影响了什么任务。4.3 低配置环境也能跑别急着把特性拉满很多人会担心自建工具需要多高配置。实际上如果你的替换目标只是满足一个小团队日常查询和十几条定时任务一台普通服务器甚至开发机都足够跑起来。瓶颈通常不在工具本身而在下游数据库。你发过去的查询越重目标库压力越大。所以判断“能不能用”时不要只看自己工具跑的顺不顺还要看目标数据库的 CPU、IOPS、慢查询数和连接占用。真正要小心的场景是从“小团队自用”切换到“全公司都在用”。这时查询数量、用户数量、任务数量都会变多原本单机部署和单人维护的假设就不成立了。这也意味着第一阶段不要做太多权限定制和并发优化先把单机版本跑稳。5. 从旧平台迁移过来时最容易翻车的几个位置5.1 迁移顺序并行跑一段时间再切断旧链路直接切断旧链路是有风险的。无论旧平台还能用多久最稳妥的方式都是让新旧两套系统并行运行一段时间。推荐的迁移顺序是第一周手动迁移高频查询把每条查询在新工具里跑一遍结果与旧工具对比第二周把一部分定时任务切到新工具但保留旧任务运行形成影子运行第三周连续多天对比新旧输出确认行数、更新时间、文件格式一致等稳定后再停掉旧工具的任务清理旧平台的账号和连接。并行运行看起来增加了工作量实际上它是最便宜的验证方式。很多迁移问题不是出现在“能不能跑”而是出现在“跑出来的结果和以前不一样”。5.2 常见翻车点按出现频率排个序根据我的经验SQL 工具迁移中翻车最多的不是 SQL 本身写错而是下面这些边界问题时区不一致。旧平台用 UTC新平台用本地时区结果每天的数据都差几小时。参数默认值丢失。原查询在界面里写死了近期日期导出后只复制了 SQL没复制参数。结果文件互相覆盖。新旧任务同时写同一个文件名导致数据不是最新而是错乱的。导出格式差异。CSV 的编码、分号、NULL 值表示方式不同下游拿到后解析失败。权限不一致。原连接账号能看到所有 schema新账号少了某张表的 SELECT 权限。通知渠道失效。换了 Webhook 地址或接口鉴权方式任务跑失败但没人收到消息。调度时间解释不同。同一段 cron 表达式在不同工具里星期几的算法可能有差异。这些问题在功能上不算大但因为都藏在任务日志和下游数据里往往要等业务方反馈才能发现。所以迁移期间的任务日志必须完整保留至少要知道每次运行用了哪个时区、哪个连接、哪些参数。5.3 迁移结束后清理动作不要省确认新旧系统运行结果一致后还应该做一遍清理关掉旧工具里仍在运行的定时任务避免重复写入下游把旧平台账号权限收回或停用降低安全隐患把已经迁移成功的 SQL 从旧平台归档导出哪怕只是留作备份整理一份连接清单和任务清单交给真正维护的人。这一轮清理容易被忽略尤其是旧任务没有立刻停掉时下游表格会出现“每天被写入两遍”的情况。数据显示没问题但所有数据的时间戳和更新频率都会变得不可信。6. 最后再想清楚三件事再决定要不要长期自建6.1 自建工具最大的成本不是开发是持续维护“因为原来工具停服所以自己写一个替代品”这个决定在短期看很有吸引力长期看需要诚实评估维护成本。自建工具上线后你会持续面对下面这些事数据库驱动需要跟随引擎版本更新操作系统、运行环境、依赖组件需要定期处理安全更新团队有人离职后连接配置和任务责任需要交接下游表格或通知渠道调整接口后你的适配代码也要跟着改。这些工作看起来琐碎但每一件都会真实占用时间。如果团队规模很小每周能分配出来的维护时间有限那么“自建”可能不是最优解。更合理的做法是先看看有没有成熟的开源替代项目或者愿意接受迁移成本的商业化产品。6.2 自建的边界在哪里什么时候该停手我在评估类似方案时会先问三个问题这个工具最多服务多少人如果长期只有十个人以内使用自建完全可行。查询和定时任务的数量级是多少几十条任务和几千条任务是两种架构。团队有没有人能长期负责如果只是“最近谁有空谁改”一到两年后很容易变成无人维护的工具。如果答案显示规模不大、维护责任人明确那么按上面四层模块自建是合适的。如果答案是需要复杂权限、海量并发和稳定 SLA那应该优先选成熟方案而不是让自建工具变成新的定时炸弹。我个人的建议是先用最小版本跑通核心闭环再用影子运行验证结果最后再决定要不要把全部历史任务迁移过去。真正值得长期维护的不是那一堆 SQL 编辑器界面而是连接、调度、日志和下游投递这些基础设施能力。