超越Bubble？2026年如何遷移至Next.js和Supabase
我在去年一年內幫助三家公司從 Bubble 遷移出來。每一家都從同樣的方式開始：團隊中有人打開月度發票，看到一個數字讓他們的胃一沉，然後開始搜尋「Bubble 替代品」。如果現在的你也是這樣，深呼吸。你並不孤單，這實際上是一個可以解決的問題。
Bubble 對於快速推出 MVP 確實很棒。我向早期創業者推薦它的次數多到數不清。但我一直看到一種模式：產品增長、團隊增長、用戶群增長 -- 突然間 Bubble 沒有跟著你增長。它正在拖累你。在 1,000 個用戶時看起來還可以的工作流單位 (WU) 定價模型在 50,000 個用戶時變成了一個嚴重的問題。當你需要自訂邏輯時，曾經感覺解放的視覺編輯器開始感覺像一個牢籠。曾經「可以接受」的頁面加載時間變得令人尷尬。
這篇文章是我第一次做這件事時希望能有的遷移指南。我們將討論為什麼團隊會超越 Bubble 的能力、2026 年實際成本是什麼樣的，以及如何實際執行到 Next.js 和 Supabase 的遷移而不會讓你的公司陷入困境。
目錄
- 為什麼團隊會超越 Bubble
- Bubble 2026 年定價現實檢查
- 為什麼 Next.js + Supabase 是正確選擇
- 架構比較：Bubble vs Next.js + Supabase
- 遷移遊戲計畫
- 資料遷移：脫離 Bubble 的資料庫
- 在 Next.js 中重建前端
- 將 Supabase 設定為後端
- 身份驗證和用戶遷移
- 遷移後的性能和成本
- 常見陷阱及如何避免
- 常見問題
為什麼團隊會超越 Bubble
讓我們具體說明「超越」實際上意味著什麼，因為這不是一件事。通常是幾個相互加複的痛點的組合。
性能瓶頸
Bubble 應用程式運行在共享基礎設施上。你的應用程式與其他 Bubble 應用程式共享計算資源。當你的應用程式流量激增時，你不能只是啟動更多實例 -- 你受到 Bubble 的擺佈。我見過有 500+ 個並發用戶的 Bubble 應用程式在基本資料庫查詢上達到 3-5 秒的響應時間。那不是 bug，那是架構。
Bubble 頁面也很重。典型的 Bubble 頁面向客戶端發送 2-4MB 的 JavaScript。與可能只發送 200-400KB 的設計良好的 Next.js 頁面相比較。你的用戶會感受到這種差異，特別是在移動設備上。
插件問題
Bubble 的插件生態系統既是它的優勢也是它的致命弱點。你會安裝用於 Stripe 集成的插件、用於 PDF 生成的插件、用於發送電子郵件的插件 -- 而每一個都由一個隨時可能在下週放棄它的隨機第三方開發者維護。我見過生產應用程式因為插件作者推送了一個不好的更新而中斷。你無法控制。
供應商鎖定是真實存在的
你的整個應用程式 -- 邏輯、資料、UI -- 都存放在 Bubble 的專有系統內。沒有「匯出我的應用程式」按鈕。你的工作流不是代碼，它們是存放在 Bubble 格式中的視覺配置。如果 Bubble 改變他們的定價（他們已經做過多次），你要麼付錢，要麼重新開始。這對任何業務都是一個可怕的談判立場。
團隊擴展問題
試著在 2026 年聘請一位「Bubble 開發者」。與 React/Next.js 開發者相比，人才池非常小。Bubble 中的版本控制與 Git 相比很原始。多個開發者同時在同一個 Bubble 應用程式上工作是一種令人沮喪的練習。沒有真正的代碼審查流程、沒有分支策略、沒有 CI/CD 管道。
Bubble 2026 年定價現實檢查
Bubble 在 2023 年轉向工作流單位 (WU) 定價，他們之後調整過多次。截至 2026 年初，以下是你看到的：
| 計畫 | 月費 | 工作流單位 | 伺服器端 WU 費率 | 客戶端 WU 費率 |
|---|---|---|---|---|
| 免費 | $0 | 有限制（僅測試） | N/A | N/A |
| Starter | $32/月 | 10,000 WU | 每個動作 1 WU | 每個動作 0.2 WU |
| Growth | $129/月 | 50,000 WU | 每個動作 1 WU | 每個動作 0.2 WU |
| Team | $349/月 | 150,000 WU | 每個動作 1 WU | 每個動作 0.2 WU |
| Enterprise | 自訂 | 自訂 | 自訂 | 自訂 |
| 超額 | 按 WU 計 | — | $0.003/WU | $0.003/WU |
這是醜陋的地方。一個擁有 10,000 個活躍用戶的中等複雜 SaaS 應用程式每月可以輕易消耗 500,000-1,000,000 WU。這是 Team 計畫之外的 $1,050-$2,550 超額費用。我見過公司在 Bubble 上支付 $3,000-$8,000/月用於可以在 $50-200/月的雲基礎設施上運行的應用程式。
WU 模型特別令人討厭，因為它對在自訂堆棧中基本上免費的事物向你收費。搜尋你的資料庫？那要花 WU。排程重複工作流程？WU。發送通知？WU。每個 API 呼叫、伺服器端的每個條件檢查 -- 這一切都加起來了。
最令人痛苦的部分是：Bubble 的定價只朝一個方向移動。WU 模型取代了舊的基於容量的定價，許多用戶看到他們的帳單在一夜之間增加了 2-5 倍。沒有保證它不會再次發生。
為什麼 Next.js + Supabase 是正確選擇
多年來我評估過數十種 Bubble 退出策略。Rails、Django、Laravel、純 React with Firebase -- 它們都是有效的。但對於特別從 Bubble 來的團隊，Next.js + Supabase 組合命中了一個很難超越的甜蜜點。
Next.js 提供 Bubble 無法提供的東西
Next.js 15（2026 年的當前穩定版本）在一個框架中提供了伺服器端渲染、靜態生成、API 路由、中介軟體和邊緣函數。你的頁面加載速度很快，因為你只發送那個頁面實際需要的 JavaScript。App Router 提供了布局、加載狀態和錯誤邊界，這些在 Bubble 中需要數十個工作流程來近似。
更重要的是，它是 React。React 生態系統是龐大的。需要日期選擇器？有 50 個經過實戰測試的選項。需要圖表？Recharts、Visx、Nivo -- 任選一個。需要身份驗證？NextAuth.js（現在是 Auth.js）或 Supabase Auth。你永遠不會被困在等待插件開發者修復 bug 上。
如果你考慮走這條路，我們的 Next.js 開發團隊已經遷移過幾個 Bubble 應用程式，並可以分享有關該過程看起來像什麼的具體細節。
Supabase 取代 Bubble 的後端
Supabase 是存在的最接近「Bubble 後端替代品」的東西。以下是原因：
- PostgreSQL 資料庫 -- 一個真實的、可查詢的、可索引的關聯式資料庫，而不是 Bubble 古怪的資料結構
- 行級安全 (RLS) -- 在資料庫級別定義誰可以讀/寫什麼資料
- 內建身份驗證 -- 電子郵件/密碼、魔法連結、OAuth 提供者，全部處理
- 實時訂閱 -- 無需輪詢的實時資料更新
- 儲存空間 -- 帶 CDN 傳遞的檔案上傳
- 邊緣函數 -- 用於自訂邏輯的無伺服器函數
Supabase 在 2026 年的定價在規模上比 Bubble 便宜得多：
| Bubble (Growth) | Supabase (Pro) + Vercel (Pro) | |
|---|---|---|
| 月度基本成本 | $129 | $25 + $20 = $45 |
| 10K 用戶時 | $349+（超額可能） | ~$75-150（使用費用） |
| 50K 用戶時 | $2,000-5,000+ | ~$200-500 |
| 100K 用戶時 | $5,000-12,000+ | ~$400-1,200 |
| 資料庫訪問 | 專有查詢 | 完整 PostgreSQL |
| 自訂代碼 | 非常有限 | 無限制 |
那些數字不是理論性的。它們基於我合作的公司的實際帳單。
架構比較：Bubble vs Next.js + Supabase
讓我們將 Bubble 的概念映射到新堆棧，這樣你就可以看到什麼去哪裡：
| Bubble 概念 | Next.js + Supabase 對應項 |
|---|---|
| 頁面 | Next.js 頁面/路由（App Router） |
| 可重複使用的元素 | React 元件 |
| 視覺元素 | JSX + Tailwind CSS / 元件函式庫 |
| 工作流程 | API 路由、伺服器動作、邊緣函數 |
| 資料庫東西 | PostgreSQL 表 |
| 資料類型和欄位 | 具有適當類型的表列 |
| 隱私規則 | Supabase 行級安全 (RLS) |
| 後端工作流程 | Supabase 邊緣函數或 cron 工作 |
| API 連接器 | 原生 fetch/axios 呼叫 |
| 插件 | npm 套件 |
| 用戶身份驗證 | Supabase Auth 或 Auth.js |
| 檔案上傳 | Supabase 儲存空間 |
| 排程 | pg_cron 或外部（Inngest、Trigger.dev） |
遷移遊戲計畫
不要嘗試一次重建所有東西。我見過那樣失敗得非常慘。這是實際有效的分階段方法。
第 1 階段：審計和計畫（1-2 週）
在寫一行代碼之前，記錄你的 Bubble 應用程式所做的一切。我是說一切：
- 映射每個頁面 -- 截圖、用戶流、每個頁面讀/寫什麼資料
- 列出所有工作流程 -- 伺服器端和客戶端、什麼觸發它們、它們做什麼
- 記錄資料模型 -- 每個資料類型、每個欄位、每個關係
- 列出所有集成 -- Stripe、SendGrid、Twilio，無論什麼插件你在使用
- 確定要削減的內容 -- 我保證有一些沒有人使用的功能。不要遷移死重量。
第 2 階段：構建基礎（2-3 週）
建立新堆棧：
npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npm install @supabase/supabase-js @supabase/ssr
設定你的 Supabase 專案、配置身份驗證、建立你的資料庫架構。這是你有機會修復你在 Bubble 中所做的所有資料建模錯誤的地方。利用適當的外鍵、索引和資料類型。
第 3 階段：構建核心功能（4-8 週）
從獲得最多流量的功能開始。在 Next.js 中正確構建它們。不要嘗試複製 Bubble 的確切 UI -- 利用此機會改進 UX。
第 4 階段：遷移資料和用戶（1-2 週）
這是令人害怕的部分，它值得有自己的部分。
第 5 階段：切換（1 週）
同時運行兩個系統，驗證一切有效，然後翻轉 DNS。將 Bubble 應用程式以唯讀模式運行幾週作為安全網。
資料遷移：脫離 Bubble 的資料庫
Bubble 讓你將資料匯出為 CSV 檔案。那是你的起點，但它不如你希望的那樣乾淨。
# 用於轉換 Bubble CSV 匯出的 Python 腳本示例
import csv
import json
from supabase import create_client
supabase = create_client(SUPABASE_URL, SUPABASE_KEY)
with open('bubble_users_export.csv', 'r') as f:
reader = csv.DictReader(f)
for row in reader:
# Bubble 以奇怪的格式匯出日期
created = convert_bubble_date(row['Created Date'])
# Bubble 使用看起來像「1677234567890x123456789」的唯一 ID
# 你會想要將這些映射到 UUID
user_data = {
'legacy_bubble_id': row['unique id'],
'email': row['email'],
'name': row['name_text'],
'created_at': created,
# 映射所有你的自訂欄位
}
supabase.table('users').insert(user_data).execute()
Bubble 資料匯出的關鍵陷阱：
- 關係儲存為 Bubble ID -- 你需要構建一個映射表以將這些轉換為你的新外鍵
- 檔案欄位匯出為 Bubble CDN URL -- 你需要在 Bubble 應用程式離線前下載這些檔案並將其重新上傳到 Supabase 儲存空間
- 列表欄位匯出為逗號分隔的 Bubble ID -- 這些需要成為適當的聯接表
- 日期格式不一致 -- 徹底測試你的日期解析
對於 Bubble Data API，你也可以以程序方式拉取資料，這有時比 CSV 匯出對大型資料集更容易：
// 從 Bubble 的 Data API 提取資料
const fetchBubbleData = async (type, cursor = 0) => {
const response = await fetch(
`https://yourapp.bubbleapps.io/api/1.1/obj/${type}?cursor=${cursor}&limit=100`,
{
headers: {
'Authorization': `Bearer ${BUBBLE_API_KEY}`
}
}
);
return response.json();
};
在 Next.js 中重建前端
一旦你看到模式，Bubble 的視覺編輯器會出人意料地對應良好到基於元件的架構。Bubble「可重複使用的元素」字面上就是一個 React 元件。Bubble「群組」是一個帶 Tailwind 類的 <div>。
這是我為在 Bubble 中資料密集型的頁面使用的模式：
// app/dashboard/page.tsx
import { createClient } from '@/lib/supabase/server';
import { DashboardStats } from '@/components/dashboard-stats';
import { RecentActivity } from '@/components/recent-activity';
export default async function DashboardPage() {
const supabase = await createClient();
const { data: stats } = await supabase
.from('user_stats')
.select('*')
.single();
const { data: activity } = await supabase
.from('activity_log')
.select('*, project:projects(name)')
.order('created_at', { ascending: false })
.limit(20);
return (
<div className="max-w-7xl mx-auto px-4 py-8">
<h1 className="text-3xl font-bold mb-8">儀表板</h1>
<DashboardStats stats={stats} />
<RecentActivity items={activity} />
</div>
);
}
注意資料提取是如何在伺服器端發生的。沒有加載微調器，沒有級聯請求。頁面完全呈現時到達。僅此一項就使應用程式感覺比 Bubble 版本快得多。
對於元件函式庫，我對 shadcn/ui 有很好的結果。它為你提供了拋光的、可訪問的元件，你擁有它們（它們被複製到你的代碼庫中，不是從套件導入）。結合 Tailwind CSS，你可以快速重建 Bubble UI，而且它們會更具響應性和效能。
將 Supabase 設定為後端
Supabase 的行級安全是你對 Bubble 隱私規則的替代品，老實說，它要強大得多：
-- 只讓用戶看到他們自己的資料
CREATE POLICY "Users can view own data"
ON user_profiles FOR SELECT
USING (auth.uid() = user_id);
-- 只讓用戶更新他們自己的配置文件
CREATE POLICY "Users can update own profile"
ON user_profiles FOR UPDATE
USING (auth.uid() = user_id);
-- 讓管理員看到一切
CREATE POLICY "Admins can view all"
ON user_profiles FOR SELECT
USING (
EXISTS (
SELECT 1 FROM user_roles
WHERE user_id = auth.uid()
AND role = 'admin'
)
);
對於後端工作流（在 Bubble 中按計劃運行的東西），Supabase 邊緣函數與 pg_cron 對大多數用例都很好用。對於更複雜的工作排程，Trigger.dev 或 Inngest 是與 Next.js 自然集成的優秀選擇。
身份驗證和用戶遷移
這是整個遷移中最棘手的部分。你的用戶在 Bubble 中存放了密碼，而你無法匯出密碼雜湊。你有兩個選項：
- 強制重置密碼 -- 向所有用戶發送一封「我們已升級我們的平臺」電子郵件，附帶密碼重置連結。簡單但會造成摩擦。
- 延遲遷移 -- 設定一個自訂身份驗證流，在首次登入時，嘗試針對 Bubble 的 API 進行身份驗證。如果成功，使用他們剛輸入的密碼在 Supabase 中建立用戶。
選項 2 需要更多工作，但提供了更好的用戶體驗。以下是大致的樣子：
// app/api/auth/migrate-login/route.ts
export async function POST(request: Request) {
const { email, password } = await request.json();
// 先嘗試 Supabase
const { data, error } = await supabase.auth.signInWithPassword({
email, password
});
if (data.user) return Response.json({ success: true });
// 如果不在 Supabase 中，嘗試 Bubble
const bubbleAuth = await authenticateWithBubble(email, password);
if (bubbleAuth.success) {
// 用相同密碼在 Supabase 中建立用戶
const { data: newUser } = await supabase.auth.admin.createUser({
email,
password,
email_confirm: true,
});
// 遷移他們的配置文件資料
await migrateUserProfile(bubbleAuth.userId, newUser.user.id);
// 將他們簽入
return Response.json({ success: true });
}
return Response.json({ error: 'Invalid credentials' }, { status: 401 });
}
遷移後的性能和成本
以下是我在 2025 年底幫助遷移的專案管理 SaaS 的真實數字：
| 度量 | 在 Bubble 上 | 遷移後 |
|---|---|---|
| 平均頁面加載時間 | 3.8 秒 | 0.9 秒 |
| 互動時間 | 5.2 秒 | 1.4 秒 |
| Lighthouse 性能 | 38 | 92 |
| 月度基礎設施成本 | $4,200 | $187 |
| 月度活躍用戶 | 12,000 | 12,000 |
| API 響應時間 (p95) | 1,800 毫秒 | 180 毫秒 |
| 正常運行時間（3 個月平均） | 99.2% | 99.97% |
單是成本降低就在兩個月內證明了遷移的合理性。性能改進在隨後的季度減少了估計 15% 的流失。
如果你看著這些數字，想著「我想要那個但沒有開發團隊來完成」，那正是我們處理的項目類型。查看我們的 無頭 CMS 和應用程式開發工作或聯絡我們進行遷移評估。
常見陷阱及如何避免
嘗試精確複製 Bubble
不要。Bubble 的做事方式通常是在基於代碼的堆棧中最糟糕的做事方式。使用遷移作為機會重新考慮用戶流和資料架構。
低估資料遷移
為資料遷移預算的時間是你認為需要的兩倍。Bubble 的資料匯出將有令人驚訝的邊界情況。你沒有預期的空值。重複記錄。孤立的關係。
忘記檔案儲存
Bubble 在他們的 CDN 上託管你上傳的檔案。當你取消 Bubble 計劃時，這些 URL 會失效。在翻轉開關之前，確保每個檔案都被下載並重新上傳到 Supabase 儲存空間。
不早期設定監控
在 Bubble 中，你不會考慮監控，因為你實際上無法對問題做任何事情。在你的新堆棧中，從第一天起設定 Sentry 進行錯誤追蹤和 Vercel Analytics（或 Plausible/PostHog）進行性能監控。
在你不應該的時候獨自進行
如果你的 Bubble 應用程式很複雜且對收入很重要，請認真考慮從已經做過這個的團隊獲得幫助。有缺陷遷移的成本 -- 遺失資料、停機時間、用戶流失 -- 遠超過專業幫助的成本。我們的定價頁面詳細說明了什麼樣的工作範圍。
常見問題
從 Bubble 遷移到 Next.js 和 Supabase 需要多長時間？
對於一個擁有 10-30 個頁面且複雜程度中等的典型 SaaS 應用程式，預計完整遷移需要 8-16 週。簡單應用程式（登錄頁面 + 儀表板 + 幾個 CRUD 功能）可以在 4-6 週內完成。複雜應用程式（許多集成、自訂邏輯和大型資料集）可能需要 16-24 週。資料遷移和用戶身份驗證過渡通常是需要比預期更長的時間的地方。
我可以逐步從 Bubble 遷移，還是必須一次全部遷移？
你絕對可以逐步進行。一個常見的方法是在 Bubble 應用程式旁邊構建新的 Next.js 應用程式，一次遷移一個功能，並使用子域路由將用戶發送到正確的版本。例如，你的新儀表板位於 app.yoursite.com，而舊功能仍在 Bubble 上運行。只要注意同時維護兩個系統有它自己的成本。
我應該考慮 FlutterFlow、WeWeb 或 Xano 等 Bubble 替代品嗎 -- 我應該考慮那些代替嗎？
如果你的主要問題是 Bubble 的定價，但你仍然想要一個無代碼/低代碼方法，WeWeb（前端）+ Xano（後端）等工具可以有效。但你正在用一個供應商鎖定換另一個。如果你超越 Bubble 是因為性能、可擴展性或團隊規模，你最終也會超越那些工具。遷移到像 Next.js + Supabase 這樣的基於代碼的堆棧是一次性投資，可以無限擴展。
運行 Next.js + Supabase 應用程式與 Bubble 相比花費多少？
對於大多數 SaaS 應用程式，你在 Vercel + Supabase 上花費 $45-200/月，這是在 Bubble 上花費 $349-5,000+/月的成本。Supabase Pro 是 $25/月，Vercel Pro 是 $20/月。按規模計算，你的成本增長要慢得多，因為你為實際計算資源付款，而不是工作流單位。粗略經驗法則：預計支付你在 Bubble 上支付的 5-20%。
遷移會影響我的 SEO 嗎？
它可以大幅改進。Bubble 應用程式是客戶端呈現且速度慢，這會損害核心網絡生命力分數。Next.js 支持伺服器端渲染和靜態生成，這意味著更快的頁面加載和更好的可爬性。只要確保你設定從舊 Bubble URL 到新 Next.js 路由的適當 301 重定向，你應該會在幾週內看到 SEO 改進。
我需要了解 PostgreSQL 才能使用 Supabase 嗎？
基本的 SQL 知識幫助很大，但 Supabase 提供了一個視覺表編輯器和一個抽象大多數查詢的 JavaScript 客戶端函式庫。也就是說，了解 SQL 將使你的效率大幅提高。對於複雜查詢、報告和性能調整，SQL 知識是必需的。如果你的團隊沒有 SQL 經驗，這是投資學習它的好時機 -- 它是一項永遠獲得回報的技能。
在遷移期間，我的 Bubble 應用程式的 API 集成會發生什麼？
你需要在 Next.js 應用程式中重新建立每個集成。好消息是，與 Bubble 的 API 連接器插件相比，這通常要容易得多。在 Bubble 中需要插件和 15 個工作流的 Stripe 集成可能在 Stripe Node.js SDK 中只有 50 行代碼。製作一份你的 Bubble 應用程式與之交談的每個外部服務的完整清單，然後一次一個地解決它們。
我可以對生產使用 Supabase 的免費層嗎？
Supabase 在 2026 年的免費層為你提供 500MB 的資料庫儲存空間、1GB 的檔案儲存空間，以及身份驗證上 50,000 個月度活躍用戶。對於非常早期的產品，這可以有效。但對於任何認真的生產應用程式，你會想要 Pro 計劃，每月 $25，以獲得更好的性能、每日備份和沒有不活動後項目暫停的情況。與 Bubble 相比，它仍然便宜得驚人。