← 返回列表
评测与安全综合合集

Pixeltable vs Supabase vs Convex:同一视频智能应用三种实现的量化对比基准

pixeltable/pixeltable-vs-supabase-vs-convex · One video intelligence app built three ways, on Pixeltable, Supabase and Convex. Every number measured, all three executed, tradeoffs stated.

GitHub原文发布 未知首次收录 2026-09-18上架 2026-09-18 07:00

☆ 收藏查看项目 ↗

ELI5:它是什么,解决什么问题

该仓库用同一份应用契约(视频抽帧、语音转写、多模态嵌入、场景检测与问答)在 Pixeltable、Supabase、Convex 三个平台上各实现一遍,并公开可复现的代码行数、编排跳数、延迟等指标与测试套件(契约测试、差分测试、韧性测试)。材料同时给出各平台在不同条件下胜负的权衡说明,包括作者承认 Pixeltable 在摄入与检索延迟上落后的场景,并明确指出实时能力、行级安全、托管数据库等场景下结论会改变。

核心能力与快速开始

★ 0 · Python

能做什么
提供三个平台(Pixeltable、Supabase、Convex)上同一视频智能管线的完整实现:抽帧、语音转写、视觉与语义嵌入、场景检测、向量检索与问答代理。仓库包含可复现的对比基准与测试:(1) 由 harness/run_comparison.py 从源码生成指标(应用代码行数、编排跳数、手写 HTTP 路由数等);(2) 每个实现 10 个契约测试、20 个实现间差分测试、32 个同时打三家的韧性测试;(3) test_recovery.py 检验失败/并发摄入行为;(4) benchmark.py 与 bench_evolve.py 分别度量大视频集下的摄入/检索耗时,以及向在线数据加列(Pixeltable 1 行 1 文件,对比 24 与 53 行)的代价。各实现均被其厂商自带检查器(deno lint、supabase db advisors、@convex-dev/eslint-plugin、tsc、ruff)约束。文档列出 Pixeltable 的若干机制:计算列随插入自动执行、Json 列可直接按路径/切片/通配符查询、检索表达式 similarity(string=q) 自行调用索引、单元格级错误列(errormsg/errortype)、pxt columns 与 pxt idxs 展示列级与表级血缘、pxt dashboard 本地 UI。文档同时列出 Pixeltable 的劣势:摄入速度落后(100 个视频时 8.04x realtime,Supabase 为 13.78x),检索延迟落后 19ms(三家均低于 56ms),但代理查询比 Supabase 快 4.5x。需要实时、行级安全或托管数据库时,结论会发生改变。
适用场景
适合在选型阶段评估以下问题:需要一个把表、计算列、索引与 HTTP 端点合并在一个 Python 文件中的视频/多模态 RAG 后端,还是需要 Supabase 的托管数据库、RLS 与实时能力,或 Convex 的响应式客户端与调度能力。也适合作为可复现的基准参考:验证“媒体处理必须放在外部计算服务(ffmpeg 无法在 Deno 或 Convex 运行时执行)”这一结构性约束,比较向在线数据加列时的迁移与回填成本,比较失败摄入会留下垃圾行还是被拒绝,以及比较请求校验错误返回 4xx 还是 5xx。
项目形态
资料合集
部署方式
三家均可本地运行在 CPU 上,不需要 API 密钥:Pixeltable 使用 pip install -e . 与 pxt init / pxt schema update / pxt service update;Supabase 与 Convex 需先启动 compute-service(pip install -e . 后 uvicorn app:app --port 9000),Convex 由 npx convex dev 自行选端口,Supabase 的 Edge Function 需要 supabase status 提供的 token。仓库未说明生产环境的部署方式、托管成本或规模上限。
主要依赖
Python;Pixeltable 需 sentence-transformers(若环境内版本低于 5.4 需升级);Supabase 需 Deno 工具链与 supabase 本地栈,Convex 需 npx convex dev 与 TypeScript;计算服务依赖 ffmpeg 相关处理。仓库说明所有模型均为本地模型,基准未实际使用任何托管模型 API,因此未说明托管的并发、限流与重试配置(文档仅描述 openai.rate_limits、anthropic.api_key 等配置项的存在)。
使用限制
作者在 TRADEOFFS.md 中明确承认 Pixeltable 在摄入和检索延迟上落后,并指出需要实时、行级安全或托管数据库时结论会改变;基准在单机上完成,作者称这一假设对需要外部计算服务的两家最有利。基准未覆盖 RLS 策略、Realtime、响应式客户端、调度器与组件。Pixeltable 没有厂商一致性检查器,仅有通用 ruff,是三家中自动验证最弱的一方。测试规模有限(如加列测试仅约两打行,作者称此时时间差异属噪声),超出该语料的结论属结构性推断而非实测。评估为单一赞助方(Pixeltable 赞助本仓库),作者称文档刻意写成可被攻击的形式并接受误读反馈。许可证 Apache-2.0,但仓库未就商用授权、API 成本或生产合规作任何说明。
许可证
Apache-2.0
最近推送
2026-09-18 06:12

资料检查:2026-09-18 07:00 · 卡片整理:2026-09-18 07:00
卡片由 AI 根据仓库资料整理,未进行安装或运行验证 · 本次更新未完成,保留上次成功内容

职业应用

程序员

作为视频智能应用后端实现的参考基准,程序员可对比 Pixeltable、Supabase、Convex 三种实现同一契约(视频抽帧、语音转写、多模态嵌入、场景检测与问答)的代码行数、编排跳数、延迟等指标,并复用其契约测试、差分测试与韧性测试套件来评估或选择技术栈。

查看内容依据
该仓库用同一份应用契约(视频抽帧、语音转写、多模态嵌入、场景检测与问答)在 Pixeltable、Supabase、Convex 三个平台上各实现一遍,并公开可复现的代码行数、编排跳数、延迟等指标与测试套件(契约测试、差分测试、韧性测试)。

官方使用入口 ↗

由 AI 根据来源材料整理,未进行安装或运行验证

这是基于来源内容整理的摘要。原文链接失效后,本页摘要和讨论仍会保留。

讨论 0

登录后参与讨论,阅读资讯无需注册。

还没有评论,来分享第一个看法。