Google 雲端資料庫入門：Firebase 與 Cloud SQL 完整教學

想用 Google 的資料庫服務，但不知道該選 Firebase 還是 Cloud SQL？這是很多開發者的困擾。

Google Cloud 的資料庫產品線其實很清楚：Firebase 適合快速開發和手機 App，Cloud SQL 適合傳統的關聯式資料需求。這篇文章會完整介紹這兩個服務，從免費方案到進階功能，手把手教你建立第一個 Google 雲端資料庫。

延伸閱讀：雲端資料庫完整指南｜了解雲端資料庫的基本概念

插圖：一張產品架構圖，中央是 Google Cloud 標誌，周圍...

場景描述： 一張產品架構圖，中央是 Google Cloud 標誌，周圍環繞著各種資料庫服務圖示（Firebase、Cloud SQL、Firestore、Spanner、Bigtable）。每個服務下方有簡短的用途說明。

視覺重點：

• Google Cloud 資料庫產品線的全貌、各服務的定位

必須出現的元素：

• Google Cloud logo、Firebase logo、各資料庫服務圖示

需要顯示的中文字： 無

顏色調性： Google 品牌色（藍、紅、黃、綠）、白色背景

避免元素： 過於複雜的連接線、抽象雲朵

Slug: google-cloud-database-services-ecosystem

---

Google Cloud 資料庫服務總覽

GCP 資料庫產品線介紹

Google Cloud 提供多種資料庫服務，各有不同定位：

服務	類型	適用場景	難度
Firebase Realtime Database	NoSQL	即時同步、手機 App	簡單
Cloud Firestore	NoSQL（文件）	手機 App、Web App	簡單
Cloud SQL	關聯式	傳統應用、MySQL/PostgreSQL	中等
Cloud Spanner	NewSQL	全球分散式、金融級	進階
Bigtable	寬列	大數據分析、IoT	進階
AlloyDB	關聯式	PostgreSQL 高效能	中等
Memorystore	快取	Redis/Memcached	中等

對大多數開發者來說，Firebase（Firestore） 和 Cloud SQL 就能滿足 90% 的需求。

Firebase vs Cloud SQL：該選哪個？

這是最常被問的問題。簡單的判斷原則：

選 Firebase / Firestore：

• 開發手機 App（iOS、Android、Flutter）
• 需要即時同步功能（聊天、協作）
• 團隊小、想快速開發
• 資料結構彈性、經常變動

選 Cloud SQL：

• 傳統的 Web 應用程式
• 資料有複雜的關聯（需要 JOIN）
• 團隊熟悉 SQL
• 需要交易一致性（ACID）
• 從既有 MySQL/PostgreSQL 遷移

兩個都用：

• Firebase 處理即時互動（聊天、通知）
• Cloud SQL 處理核心業務資料（訂單、帳務）

與 AWS、Azure 的差異

想了解三大平台的完整比較？看這篇：AWS、GCP、Azure 資料庫完整比較

GCP 的獨特優勢：

• Firebase：即時同步做得最好，手機 SDK 最完整
• Spanner：全球分散式一致性，其他平台沒有同等產品
• BigQuery：Serverless 分析查詢，速度和成本都很有競爭力
• 台灣資料中心：彰化有機房，延遲低、資料落地

GCP 的劣勢：

• 資料庫服務數量比 AWS 少
• 社群資源和文件比 AWS 少
• 某些進階功能較晚推出

---

Firebase 資料庫完整教學

Firebase 是 Google 的 App 開發平台，資料庫是其中最核心的功能。

Realtime Database vs Firestore 比較

Firebase 有兩種資料庫，很多人搞混：

比較項目	Realtime Database	Cloud Firestore
資料模型	JSON 樹狀結構	文件集合（Document-Collection）
查詢能力	有限	較強（複合查詢、排序）
離線支援	✅	✅（更完整）
擴展性	單區域	多區域、自動擴展
定價模式	依資料量和下載	依讀寫次數和儲存
推薦程度	舊專案維護	新專案首選

結論：新專案請直接用 Firestore。Realtime Database 是舊版，功能較受限。

Firebase 免費方案詳解

Firebase 的免費額度很大方。更多免費選項：免費雲端資料庫完整清單

Firestore 免費額度（Spark 方案）：

項目	免費額度
儲存空間	1 GB
文件讀取	50,000 次/天
文件寫入	20,000 次/天
文件刪除	20,000 次/天
網路流出	10 GB/月

Realtime Database 免費額度：

項目	免費額度
儲存空間	1 GB
下載流量	10 GB/月
同時連線	100

這些額度足夠做：

• 個人專案和 side project
• MVP 驗證
• 小型應用（每天幾百到幾千用戶）

建立第一個 Firebase 資料庫

Step 1：建立 Firebase 專案

1. 前往 Firebase Console
2. 點選「新增專案」
3. 輸入專案名稱
4. 選擇是否啟用 Google Analytics（建議啟用）
5. 完成建立

Step 2：建立 Firestore 資料庫

1. 在左側選單點選「Firestore Database」
2. 點選「建立資料庫」
3. 選擇模式：
   • 測試模式：任何人都能讀寫（開發用）
   • 正式模式：需要設定安全規則
4. 選擇位置：asia-east1（台灣）
5. 點選「建立」

Step 3：新增資料

在 Console 介面直接新增：

1. 點選「開始收集」
2. 輸入集合 ID（例如：users）
3. 新增文件（自動產生 ID 或自訂）
4. 新增欄位和值

或用程式碼：

// Web SDK
import { initializeApp } from 'firebase/app';
import { getFirestore, collection, addDoc } from 'firebase/firestore';

const firebaseConfig = {
  apiKey: "YOUR_API_KEY",
  authDomain: "YOUR_PROJECT.firebaseapp.com",
  projectId: "YOUR_PROJECT_ID",
};

const app = initializeApp(firebaseConfig);
const db = getFirestore(app);

// 新增資料
async function addUser() {
  const docRef = await addDoc(collection(db, "users"), {
    name: "張小明",
    email: "[email protected]",
    createdAt: new Date()
  });
  console.log("Document ID:", docRef.id);
}

Step 4：查詢資料

import { getDocs, query, where } from 'firebase/firestore';

// 查詢所有用戶
const querySnapshot = await getDocs(collection(db, "users"));
querySnapshot.forEach((doc) => {
  console.log(doc.id, " => ", doc.data());
});

// 條件查詢
const q = query(
  collection(db, "users"),
  where("email", "==", "[email protected]")
);
const results = await getDocs(q);

資料結構設計最佳實踐

Firestore 的資料結構和 SQL 很不一樣，需要換個思維：

原則一：反正規化（Denormalization）

SQL 習慣把資料拆開，用 JOIN 組合。Firestore 建議把常用的資料放在一起。

// SQL 思維（不建議）
// users 集合
{ id: "user1", name: "張小明" }
// orders 集合
{ id: "order1", userId: "user1", product: "iPhone" }

// Firestore 思維（建議）
// orders 集合 - 直接包含用戶資訊
{
  id: "order1",
  product: "iPhone",
  user: {
    id: "user1",
    name: "張小明"
  }
}

原則二：用子集合組織資料

// 用戶的訂單用子集合
// users/{userId}/orders/{orderId}

// 新增子集合文件
await addDoc(
  collection(db, "users", "user1", "orders"),
  { product: "iPhone", price: 35000 }
);

原則三：避免深層巢狀

Firestore 建議最多 2-3 層。太深會影響查詢效能和可維護性。

安全規則設定

Firestore 安全規則決定誰能讀寫資料。測試模式很危險，上線前一定要設定。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // 用戶只能讀寫自己的資料
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }

    // 訂單只有登入用戶能讀，只有擁有者能寫
    match /orders/{orderId} {
      allow read: if request.auth != null;
      allow write: if request.auth != null
                   && request.auth.uid == resource.data.userId;
    }

    // 公開資料任何人都能讀
    match /public/{document=**} {
      allow read: if true;
      allow write: if false;
    }
  }
}

插圖：一個步驟流程圖，顯示建立 Firebase 專案的過程。從建...

場景描述： 一個步驟流程圖，顯示建立 Firebase 專案的過程。從建立專案 → 選擇服務 → 設定資料庫 → 寫入資料，每個步驟有對應的螢幕截圖縮圖。

視覺重點：

• 清晰的步驟流程、Firebase Console 介面元素

必須出現的元素：

• Firebase logo、步驟編號、Console 介面示意

需要顯示的中文字： 無

顏色調性： Firebase 橙黃色、白色背景

避免元素： 過於複雜的截圖、抽象圖形

Slug: firebase-project-setup-configuration-steps

---

Cloud SQL 完整教學

Cloud SQL 是 Google Cloud 的關聯式資料庫託管服務，支援 MySQL、PostgreSQL、SQL Server。

Cloud SQL 支援的資料庫引擎

引擎	支援版本	特色
MySQL	5.7、8.0	最多人用，資源豐富
PostgreSQL	12-16	功能最強，擴充套件多
SQL Server	2017-2022	微軟生態系整合

選擇建議：

• 已有經驗：選熟悉的引擎
• 新專案：PostgreSQL 功能最完整
• 要遷移：選和來源相同的引擎

建立 Cloud SQL 執行個體

Step 1：進入 Cloud SQL

1. 登入 GCP Console
2. 搜尋「Cloud SQL」
3. 點選「建立執行個體」

Step 2：選擇資料庫引擎

選擇 MySQL、PostgreSQL 或 SQL Server。這邊以 MySQL 為例。

Step 3：設定執行個體

執行個體 ID：my-mysql-db（自訂，之後不能改）
密碼：設定 root 密碼（要記住！）
資料庫版本：MySQL 8.0
區域：asia-east1（台灣）
可用區可用性：
  - 單一可用區：較便宜，適合開發
  - 多可用區（高可用性）：正式環境建議

Step 4：設定機器規格

機器類型：
  - 共用核心：最便宜，適合測試
  - 輕量：小型應用
  - 標準：一般用途
  - 高記憶體：大型資料庫

建議從小規格開始，之後可以升級。

Step 5：設定儲存空間

儲存類型：SSD（建議）或 HDD
儲存容量：依需求，可以自動增加
啟用自動儲存空間增加：建議開啟

Step 6：設定連線

公開 IP：
  - 不勾選：只能從 GCP 內部連線（較安全）
  - 勾選：可以從外部連線（需設定授權網路）

私有 IP：建議啟用（從 VPC 內連線）

授權網路：加入你的 IP（如果用公開 IP）

Step 7：建立

點選「建立執行個體」，等待約 5-10 分鐘。

MySQL 連線設定

詳細的 MySQL 連線教學：MySQL 雲端整合完整指南

方法一：Cloud SQL Proxy（推薦）

最安全的連線方式，不需要設定公開 IP。

# 下載 Cloud SQL Proxy
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.8.0/cloud-sql-proxy.linux.amd64
chmod +x cloud-sql-proxy

# 執行（需要先設定 gcloud 認證）
./cloud-sql-proxy --port 3306 PROJECT_ID:REGION:INSTANCE_NAME

# 另一個終端連線
mysql -u root -p -h 127.0.0.1

方法二：公開 IP 連線

# 先在 Console 設定授權網路（你的 IP）
# 然後直接連線
mysql -u root -p -h [CLOUD_SQL_PUBLIC_IP] --ssl-mode=REQUIRED

方法三：程式碼連線

# Python + SQLAlchemy
from sqlalchemy import create_engine

# 使用 Cloud SQL Proxy
engine = create_engine(
    'mysql+pymysql://user:[email protected]:3306/database'
)

# 或使用公開 IP + SSL
engine = create_engine(
    'mysql+pymysql://user:password@PUBLIC_IP:3306/database',
    connect_args={
        'ssl': {
            'ca': 'server-ca.pem',
            'cert': 'client-cert.pem',
            'key': 'client-key.pem'
        }
    }
)

效能調校與監控

1. 使用 Cloud SQL Insights

GCP 內建的效能分析工具：

• 查看 CPU、記憶體、連線數趨勢
• 找出慢查詢
• 分析查詢計畫

在 Console 的執行個體頁面點選「Query Insights」。

2. 調整資料庫參數

在「資料庫旗標」中可以調整 MySQL 參數：

innodb_buffer_pool_size：調大可改善效能
max_connections：依需求調整
slow_query_log：啟用以找出慢查詢

3. 設定告警

在 Cloud Monitoring 設定告警：

• CPU > 80% 持續 5 分鐘
• 記憶體 > 85%
• 儲存空間 > 80%
• 連線數接近上限

---

其他 GCP 資料庫服務

Cloud Spanner（全球分散式）

Spanner 是 Google 的獨門技術，全球分散式資料庫同時保證強一致性。

適合場景：

• 全球化應用，需要多區域部署
• 金融系統，需要強一致性
• 超大規模，需要水平擴展

價格： 很貴，每節點每小時約 $0.9 起。小專案不適合。

Bigtable（大數據分析）

Bigtable 是 Google 內部用的大數據資料庫，支撐了 Gmail、YouTube 等服務。

適合場景：

• IoT 資料收集（每秒數萬筆寫入）
• 時序資料分析
• 大規模機器學習特徵儲存

價格： 依節點和儲存計費，最低也要每月數百美金。

Memorystore（Redis/Memcached）

託管的記憶體快取服務。

適合場景：

• Session 儲存
• 快取熱門資料
• 排行榜、計數器

價格： 比自己架 Redis 貴，但省維運時間。小專案可以考慮用 Firestore 或應用層快取替代。

---

GCP 資料庫費用解析

計費方式說明

Firestore 計費：

• 文件讀取：$0.06 / 10 萬次
• 文件寫入：$0.18 / 10 萬次
• 文件刪除：$0.02 / 10 萬次
• 儲存：$0.18 / GB / 月
• 網路流出：$0.12 / GB

Cloud SQL 計費：

• 運算：依 vCPU 和記憶體計費
• 儲存：$0.17 / GB / 月（SSD）
• 網路：同區域免費，跨區域收費
• 備份：超過免費額度後收費

免費額度與試用金

服務	免費內容
Firestore	1GB 儲存 + 每天 5 萬讀取（永久）
Cloud SQL	無免費額度
GCP 新帳號	$300 試用金（90 天）

$300 試用金可以跑一個小型 Cloud SQL 執行個體約 2-3 個月。

成本優化技巧

1. 選對服務

• 小專案用 Firestore，免費額度很夠
• 需要 SQL 才用 Cloud SQL

2. 選對規格

• 從最小規格開始
• 監控實際使用量再升級

3. 用承諾使用折扣

• 確定長期使用，買 1 年或 3 年承諾
• 可省 25-52%

4. 開發環境省錢

• 開發用最小規格
• 不用時停止執行個體（注意仍收儲存費）

---

不確定該選 Firebase 還是 Cloud SQL？ 選錯了之後要遷移很麻煩。預約免費諮詢，讓我們幫你評估最適合的方案。

---

使用情境與推薦方案

行動應用程式

推薦：Firebase（Firestore）

原因：

• SDK 完整，iOS/Android/Flutter 都支援
• 即時同步，資料一改 App 馬上更新
• 離線支援，沒網路也能用
• 和 Firebase Auth、Cloud Messaging 整合好

架構範例：

手機 App ←→ Firestore（主要資料）
         ←→ Firebase Auth（登入）
         ←→ Cloud Storage（圖片）

Web 應用程式

看情況選擇：

簡單的 SPA / JAMstack： Firestore

• 前端直接連 Firestore
• 用安全規則控制權限
• 免費額度通常夠用

傳統的 Server-side 應用： Cloud SQL

• 後端連 Cloud SQL
• 完整的 SQL 功能
• 適合複雜的商業邏輯

混合架構： 兩者都用

• Cloud SQL 存核心資料（訂單、帳務）
• Firestore 處理即時功能（通知、聊天）

企業級應用

推薦：Cloud SQL + 高可用性配置

設定建議：

• 啟用高可用性（Multi-AZ）
• 設定讀取副本（Read Replica）
• 啟用自動備份，保留 30 天
• 使用私有 IP，不開公開 IP
• 設定 Cloud Armor 防護

如果需要全球部署：

• 考慮 Cloud Spanner
• 或用多個 Cloud SQL 執行個體 + 應用層路由

插圖：一個決策流程圖，從「你要做什麼應用？」開始，分支到手機 Ap...

場景描述： 一個決策流程圖，從「你要做什麼應用？」開始，分支到手機 App、Web 應用、企業系統，每個分支指向推薦的資料庫服務。

視覺重點：

• 清晰的決策路徑、每種情境的推薦方案

必須出現的元素：

• 決策節點、箭頭流程、Firebase 和 Cloud SQL 的識別

需要顯示的中文字： 無

顏色調性： Google 品牌色、白色背景、清晰的流程線

避免元素： 過於複雜的分支、抽象圖形

Slug: database-selection-guide-by-use-case

---

常見問題 FAQ

Firebase 免費額度夠用嗎？

對大多數小型應用來說，夠用。每天 5 萬次讀取可以支撐：

• 約 500-1000 個日活用戶（一般使用）
• 約 100-200 個日活用戶（重度讀取）

超過免費額度會自動收費（如果是 Blaze 方案）。建議在 Console 設定預算警示。

Cloud SQL 和自建 MySQL 差在哪？

項目	Cloud SQL	自建 MySQL
硬體維護	Google 負責	你負責
安全更新	自動	你負責
備份	內建自動備份	你要設定
高可用性	勾選就有	要自己建
成本	按月付費	硬體攤提 + 人力
彈性	隨時升降規格	要買新機器

小結：Cloud SQL 省事但每月要付費，自建省錢但要花時間維護。

可以從 Firebase 遷移到 Cloud SQL 嗎？

可以，但不簡單。Firebase（NoSQL）和 Cloud SQL（SQL）的資料模型完全不同：

需要做的事：

1. 重新設計資料結構（反正規化 → 正規化）
2. 寫遷移腳本轉換資料
3. 修改應用程式的資料存取邏輯
4. 測試所有功能

建議： 一開始就想清楚用哪個。如果不確定，Firestore 的查詢能力比較接近 SQL，之後要遷移會比 Realtime Database 容易一點。

---

結論

Google Cloud 的資料庫選擇其實很清楚：

需求	推薦服務
手機 App 開發	Firebase（Firestore）
需要即時同步	Firebase（Firestore）
需要完整 SQL	Cloud SQL
從 MySQL/PostgreSQL 遷移	Cloud SQL
全球分散式	Cloud Spanner
大數據分析	Bigtable + BigQuery

快速開始建議

1. 新手 / 小專案：從 Firestore 開始，免費額度夠用
2. 需要 SQL：用 Cloud SQL，從最小規格開始
3. 不確定：先用 Firestore 做 MVP，需要 SQL 功能再評估遷移

---

讓 Google Cloud 幫你省錢又省事

Google Cloud 的產品線很豐富，選對服務能省下不少錢和時間。但選錯了，就是花冤枉錢和走冤枉路。

CloudInsight 免費雲端諮詢 可以幫你：

✅ 需求分析：了解你的應用需求，推薦最適合的服務 ✅ 架構設計：規劃 Firebase + Cloud SQL 的混合架構 ✅ 成本優化：確保你不會為用不到的功能付費 ✅ 遷移協助：從其他平台遷移到 GCP 的規劃和執行

我們是 Google Cloud Partner，對 GCP 的各種服務都很熟悉。

預約免費諮詢

點我預約 30 分鐘免費諮詢

不管你是剛開始評估 GCP，還是想優化現有架構，我們都能給你專業建議。

---

延伸閱讀

• 雲端資料庫完整指南
• 免費雲端資料庫完整清單
• AWS vs GCP vs Azure 資料庫完整比較
• MySQL 雲端資料庫整合指南

---

參考資料

1. Google Cloud - Cloud SQL Documentation
2. Firebase - Cloud Firestore Documentation
3. Google Cloud - Choosing a Database
4. Firebase Pricing Calculator
5. Google Cloud Pricing Calculator
6. Google Cloud - Best Practices for Cloud SQL