estel_docs/content/blog/1.技术栈/991.从Supabase迁移到Appwrite.md

title, description, date, img, navigation

title	description	date	img	navigation
从Supabase迁移到Appwrite	AI 扩写	2025-07-01	https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250623164451378.png	icon simple-icons:supabase

最初的技术选型

去年春节前开发AI平台时，我在后端服务的选择上——Github社区有两个优秀的开源项目：Supabase和Appwrite。

当时的决策因素：

1. 社区热度：Supabase的Star数量明显更多
2. UI设计：后台管理界面的配色和布局更符合我的审美
3. 命名偏好：单纯喜欢"Supabase"这个名字的科技感
4. 商业化支持：国内有memfire cloud这样的二开商业项目
5. 退出策略：不想自托管时可以有现成的过渡方案

使用后的痛点

随着项目的深入开发，我逐渐感受到了一些问题：

• 系统太重：Supabase的"全家桶"式设计带来了不必要的复杂度
• 功能过剩：很多内置功能在项目中根本没有用到
• 维护成本：自托管的运维负担超出预期

Appwrite

上个月Appwrite发布的Sites功能让我眼前一亮——这个对标Vercel的新功能完全改变了我对它的认知。经过重新评估：

✅ 更轻量的架构
✅ 恰到好处的功能集
✅ 持续创新的能力

迁移计划

现在已经着手准备后端迁移：

1. 收集双方的SDK文档
2. 制定cursor-rules转换规则
3. 利用AI辅助代码转换

嘿，这告诉我们： 技术选型时除了看表面参数，更应该深入评估：

• 项目的实际需求
• 长期维护成本
• 技术栈的发展潜力

这次迁移虽然会带来短期工作量，但从长期来看绝对是值得的！