2026年從Bubble遷移到Next.js + Supabase

你的月度發票寄來，那個數字讓你停下來——847美元的工作流程單位，又來了。你打開新標籤頁，在搜尋欄輸入「Bubble替代品」。去年有三位創辦人做過完全相同的事。他們每個人都以為自己陷入了困境。他們其實沒有。他們真正做的是驗證了產品市場契合度，使其足以強大到Bubble基於使用量的定價無法隨之擴展。根據他們的工作流程中有多少自訂邏輯，遷移到Next.js和Supabase耗時四到九週。其中一個在第二個月就節省了640美元/月。另一個將頁面載入時間從3.2秒縮短到680毫秒，並看到他們的註冊轉換率上升了11個百分點。如果你的Bubble應用程式能正常運作，但單位經濟學不合理，你即將看到遷移的確切分解——包括真實程式碼、真實時間表，以及決定你是在四週還是四個月內發貨的三個決策。

Bubble對於讓MVP上線確實很棒。我向早期創辦人推薦過無數次。但我一直看到一個模式：產品成長、團隊成長、使用者基數成長——突然間Bubble不再與你一起成長。它在阻礙你。工作流程單位(WU)定價模式在1000個使用者時看起來還不錯，但在50000個使用者時就變成了嚴重的問題。視覺編輯器在開始時感覺很自由，當你需要自訂邏輯時就像是被囚禁的感覺。曾經「可接受」的頁面載入時間現在變成令人尷尬的。

這篇文章是我第一次做這個時希望擁有的遷移指南。我們將討論為什麼團隊會超越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費率
Free	$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

這就是醜陋的地方。一個具有10000個活躍使用者的中等複雜SaaS應用程式每月可以輕鬆燃燒500000-1000000個WU。那是1050-2550美元的超額費用加上Team方案。我見過公司在Bubble上支付3000-8000美元/月，而這些應用程式可以在50-200美元/月的雲基礎設施上運行。

WU模型特別令人懲罰，因為它對在自訂堆疊中基本上免費的事物收費。搜尋你的資料庫？那要花WU。排程定期工作流程？WU。傳送通知？WU。每個API呼叫、伺服器端的每個條件檢查——全部加起來。

最令人難受的部分是：Bubble的定價只朝著一個方向發展。WU模型取代了舊的基於容量的定價，許多使用者的帳單在一夜之間增加了2-5倍。沒有保證它不會再次發生。

為什麼選擇Next.js + Supabase

我這些年評估過數十種Bubble退出策略。Rails、Django、Laravel、普通React與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。

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 Storage
排程	pg_cron或外部(Inngest、Trigger.dev)

遷移遊戲手冊

不要嘗試一次性重建所有內容。我見過這失敗得非常糟。以下是實際有效的分階段方法。

第1階段：審計和規劃(1-2週)

在寫一行程式碼之前，記錄你的Bubble應用程式所做的一切。我是認真的，一切：

1. 對應每一頁 ——截圖、使用者流程、每一頁讀取/寫入什麼資料
2. 編目所有工作流程 ——伺服器端和用戶端、什麼觸發它們、它們做什麼
3. 記錄資料模型 ——每個資料型別、每個欄位、每種關係
4. 列出所有整合 ——Stripe、SendGrid、Twilio，無論你使用什麼外掛程式
5. 確定要切割的內容 ——我保證有人未使用的功能。不要遷移死重量。

第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 Storage
• 列表欄位匯出為逗號分隔的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中儲存了密碼，你無法匯出密碼雜湊。你有兩個選項：

1. 強制密碼重設 ——向所有使用者發送「我們已升級平台」電子郵件，附帶密碼重設連結。簡單但會造成摩擦。
2. 懶惰遷移 ——設定自訂驗證流程，第一次登入時，嘗試對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的資料匯出會有令你驚訝的邊界案例。在你未期望的地方有null值。重複記錄。孤立的關係。

忘記檔案儲存

Bubble在他們的CDN上託管你上傳的檔案。當你取消Bubble計劃時，這些URL就消失了。確保在翻動開關之前，每個單一檔案都被下載並重新上傳到Supabase Storage。

未早期設定監控

在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上運行。只要意識到同時維護兩個系統有其自身成本。

Bubble替代品如FlutterFlow、WeWeb或Xano怎麼樣——我應該考慮那些嗎？

如果你的主要問題是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應用程式是用戶端渲染和緩慢的，這傷害了核心Web生命值分數。Next.js支援伺服器端渲染和靜態產生，這意味著頁面載入更快和更好的可爬網性。只要確保你設定了從舊Bubble URL到新Next.js路由的適當301重新導向，你應該會在幾週內看到SEO改進。

我需要知道PostgreSQL才能使用Supabase嗎？

基本的SQL知識幫助很大，但Supabase提供視覺化表格編輯器和JavaScript用戶端庫，將大多數查詢抽象化。那說，理解SQL會使你大幅更有效。對於複雜查詢、報告和效能調整，SQL知識是必要的。如果你的團隊沒有SQL經驗，這是投資學習它的好時機——這是一項永遠報酬豐厚的技能。

在遷移期間，我的Bubble應用程式的API整合會發生什麼？

你需要在Next.js應用程式中重建每個整合。好消息是，這通常比Bubble的API Connector外掛程式和15個工作流程容易得多。在Bubble中需要外掛程式和15個工作流程的Stripe整合可能只是50行程式碼加上Stripe Node.js SDK。建立完整清單，列出你的Bubble應用程式與之溝通的每個外部服務，並一次處理一個。

我可以將Supabase的免費層用於生產嗎？

Supabase在2026年的免費層給你500MB資料庫儲存、1GB檔案儲存，驗證上50000個每月活躍使用者。對於非常早期的產品，這可以有效。但對於任何認真的生產應用程式，你會想要Pro計劃，價格為$25/月，以獲得更好的效能、每日備份，和沒有專案在不活動後暫停。它仍然比Bubble便宜得令人可笑。