---
title: 从Supabase迁移到Appwrite
description: AI 扩写
date: 2025-07-01
img: https://lijue-me.oss-cn-chengdu.aliyuncs.com/20250623164451378.png
navigation:
  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辅助代码转换

**嘿，这告诉我们**：
技术选型时除了看表面参数，更应该深入评估：
- 项目的实际需求
- 长期维护成本
- 技术栈的发展潜力

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