50 lines
1.7 KiB
Markdown
50 lines
1.7 KiB
Markdown
---
|
||
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辅助代码转换
|
||
|
||
**嘿，这告诉我们**：
|
||
技术选型时除了看表面参数，更应该深入评估：
|
||
- 项目的实际需求
|
||
- 长期维护成本
|
||
- 技术栈的发展潜力
|
||
|
||
这次迁移虽然会带来短期工作量，但从长期来看绝对是值得的！
|