公司的專案清單、客戶名單、內容排程，很多團隊的第一版都長在 Notion 裡：一開始只是幾頁筆記，後來有人把清單轉成資料庫、加了屬性、拉出看板，儼然是一套小系統。接著資料越積越多、用的人越來越雜，頁面打開要等、權限開始說不清楚、想加個自動提醒卻發現卡在方案，於是那個典型的問題出現了：Notion 資料庫到底能撐到哪裡？
這條路值得整段走一遍：先把資料庫的基本功用對（屬性、檢視、篩選），再把 Relation 與 Rollup 這兩個進階功能講到能上手，然後誠實檢視資料量變大後常撞到的三道瓶頸，最後對照 Lark Base 這類線上資料庫，說清楚什麼時候值得搬、怎麼搬。利益先揭露：我們是 Lark 台灣授權代理商，立場自然有偏向，所以只做可被檢驗的事，Notion 的每一項行為都以官方幫助中心文件為準（查核日期 2026-08-07），Lark 的每一項行為都附站內知識中心或定價頁出處。
先把 Notion 資料庫用對：屬性、檢視、篩選
Notion 官方把資料庫定義為「頁面的集合」：每一筆項目都是一頁可以打開編輯的頁面，這是它跟一般表格最根本的差別（官方說明，2026-08-07 查核）。一般表格的一列就只是一列；Notion 的每個項目點開來是完整頁面，會議紀錄、規格說明、參考連結都能放進內文。清單與筆記長在同一個地方，正是它讓人黏著的原因。
結構化的部分靠屬性（property）。官方的說法是屬性為項目加上各種脈絡資訊，例如截止日、負責人、相關連結、最後編輯時間；類型包含文字、數字、單選（Select）、狀態（Status）、多選、日期、人員、檔案、核取方塊、公式，以及後面會展開的 Relation 與 Rollup 等（屬性文件）。用對屬性有一條簡單的原則：凡是之後要拿來篩選、排序、統計的資訊，一律做成屬性；只給人讀的敘述，放頁面內文。跟進狀態用單選或狀態屬性把選項定死，不要用文字屬性自由填，之後的看板分組與統計才有意義。
**檢視（view）**是同一包資料的不同版面。官方目前列出七種版面：表格（Table）、看板（Board）、時間軸（Timeline）、行事曆（Calendar）、清單（List）、圖庫（Gallery）、圖表（Chart），另有與資料庫相接的表單（檢視與篩選文件）。同一張任務資料庫，執行的人用看板依狀態分組，管進度的人用時間軸看排程，資料始終只有一份。
篩選與排序決定每個檢視顯示什麼。篩選讓資料庫只顯示符合條件的項目；需要複雜條件時可用進階篩選，把 AND 與 OR 組成篩選群組，官方載明最多可巢狀三層。排序依屬性值排列，文字依字母、數字依大小，單選與多選還能自訂選項順序。實務上最划算的一招，是替自己存一個「我的未完成」檢視：篩選負責人是自己、狀態未完成，每天打開就是待辦清單。
Relation 與 Rollup：把兩張表接起來
Relation（關聯）負責把兩個資料庫的項目接在一起，Rollup（彙總）負責站在這條關聯上把對方的資料抓過來計算；先有 Relation，才有 Rollup（官方文件，2026-08-07 查核）。這兩個功能是 Notion 資料庫從「清單」升級成「系統」的分水嶺，也是多數教學停下來的地方。
為什麼需要關聯？因為真實的業務資料很少只有一張表。客戶是一張表、訂單是一張表，硬塞成一張的下場是客戶資訊在每筆訂單重複一次，改一個電話要改十處。官方對 Relation 的定位就是用來表達不同資料庫項目之間的關係：在訂單資料庫新增屬性、類型選 Relation、指到客戶資料庫，每筆訂單就能掛上所屬客戶。建立時打開「Show on⋯」開關可以變成雙向關聯，客戶那邊也會多出一個屬性，列出這個客戶名下的所有訂單；記得替對向屬性取個像樣的名字，不要留著預設值。另外，Relation 屬性可以設定可連結的頁面數，選單一頁面或不限，適合用來限制「一筆訂單只能屬於一個客戶」。
Rollup 則把關聯變成數字。前提是資料庫之間已有 Relation，接著選這條關聯、選對方要彙總的屬性、選計算方式：計數、去重計數、加總、平均、中位數、最大最小值、最早或最晚日期等。常見組合：客戶頁面用 Rollup 加總名下訂單金額，就是簡易的客戶貢獻表；專案頁面用 Rollup 計算已完成任務數，就是進度儀表。新手最常見的卡關是直接找 Rollup 卻找不到資料來源，原因多半是還沒建 Relation；順序固定：先關聯、後彙總。
資料量變大後的三道瓶頸
Notion 資料庫的瓶頸通常不出現在功能清單上，而出現在資料量與協作人數成長之後的日常：載入速度、權限顆粒、自動化能力，是換工具討論裡最常見的三條導火線。以下分開講，每一條先講證據等級，再講實務影響。
載入速度：官方沒有數字，社群回報不少
資料庫變慢，是三道瓶頸中最常被抱怨、也最難拿出官方數字的一道。資料筆數多、Relation 與 Rollup 疊得深的工作區，開資料庫要等、切檢視要等，是資料量成長後常見的社群回報；不過體感受網路環境、資料結構與裝置影響，官方幫助中心並沒有承諾任何載入時間，也沒有把速度列為已知限制，所以這條請當成「值得用自家資料量實測」的風險項，而不是定論。
能對照的官方訊號是屬性上限。官方文件載明，為了讓資料庫保持快速與可靠，每個資料庫最多可有 500 個屬性，達到上限後要先刪屬性才能再新增（2026-08-07 查核）。結構複雜度會影響效能這件事，官方是用「設上限」的方式回應的。評估時比較實際的做法：把你們最大那張表的真實資料倒進去用一週，比看任何評測都準。
權限顆粒：控管單位是頁面，不是記錄
Notion 官方權限說明所列的層級共六種：完整存取（Full access）、可編輯（Can edit）、可編輯內容（Can edit content）、可建立（Can create）、可評論（Can comment）、可檢視（Can view），控管的單位是工作區、團隊空間、頁面與資料庫（權限文件，2026-08-07 查核）。其中資料庫專用的「可編輯內容」允許成員在資料庫裡新增與編輯項目、修改屬性值，但不能更動資料庫結構；另一個資料庫專用層級「可建立」（Can create），官方載明屬 Business 與 Enterprise 方案權益。子頁面則預設繼承父頁面的權限。
拿台灣企業常見的兩個需求來對照：「業務只能看到自己名下那幾筆客戶」「成本欄位只開放主管」。這種以單筆記錄、單一欄位為單位的權限規則，不在官方權限說明所列的層級選項內（以官方最新文件為準）；實務上要達到類似效果，通常得把資料拆成多個資料庫或頁面，用存取範圍去繞，資料一拆，重複與不同步就跟著來。權限顆粒粗，在十個人的團隊是小事，在部門級系統是天天摩擦的事。
自動化：觸發範圍與方案界線
Notion 資料庫自動化的官方定義，是當資料庫發生特定變化時執行的一連串動作：觸發條件包含新增頁面時、指定屬性被修改時、以固定頻率定期執行；動作包含編輯屬性、在指定資料庫新增或編輯頁面、發送通知、寄送郵件、發送 Webhook 與 Slack 通知等（自動化文件，2026-08-07 查核）。觸發範圍以資料庫自身的變化為中心；對外串接則落在寄送郵件、Webhook 與 Slack 通知這幾類動作上。
方案界線要攤開講：官方載明資料庫自動化屬付費方案功能；免費方案只能建立 Slack 通知類自動化，範本內建的自動化可以使用但不能編輯（以官方最新公告為準）。對日常溝通不在 Slack 上的台灣團隊，免費方案能用的那一類通知其實幫不上忙；想把提醒、流程交給系統，就要把升級成本跟其他需求一起算。
三道瓶頸都不否定 Notion 的強項。項目即頁面的設計，讓筆記、文件與資料庫長在同一個地方，對個人與小團隊的知識管理依然流暢；資料量不大、權限需求單純的話，繼續深耕是合理選擇。瓶頸真正的用途是幫你分辨：痛點來自還沒用熟，還是來自產品的設計單位。前者該練功，後者該評估搬家。
需要「真的資料庫」時：Lark Base 對照
Lark 多維表格（Base）是表格形態的線上資料庫：欄位有型別、權限能切到單筆記錄與單一欄位、例行規則交給自動化執行，對準的正是資料量與協作複雜度上來之後的需求。對照之前重申立場：我們代理 Lark，以下每一格都附出處，歡迎逐條檢驗；No-Code 工具的整體選型邏輯，另見No-Code 平台完整指南。
先對齊術語，兩邊的概念幾乎一一對應：Notion 的屬性，約等於 Base 的欄位（欄）；Notion 的項目，約等於 Base 的記錄（列）；Notion 的 Relation，對應 Base 的單向與雙向關聯欄位；Rollup 的彙總計算，對應 Base 的查找引用欄位，需要更複雜的統計還有支援跨表整列引用的公式欄位。學過前兩段的操作，換平台不必重學概念。
| 面向 | Notion 資料庫（官方幫助中心，2026-08-07 查核） | Lark Base（站內知識中心＋定價頁現值） |
|---|---|---|
| 資料單位 | 項目即頁面，資料庫是頁面的集合 | 記錄（列）配欄位（欄），欄位有型別 |
| 欄位／屬性 | 文字、數字、單選、狀態、日期、人員、公式、Relation、Rollup 等；單一資料庫上限 500 個屬性 | 常規、業務、高級三大類，含公式、查找引用、單向與雙向關聯等 |
| 檢視 | 表格、看板、時間軸、行事曆、清單、圖庫、圖表七種版面，另有表單 | 表格、看板、日曆、畫冊、甘特、表單六種檢視，各檢視共用同一份資料 |
| 跨表關聯 | Relation 建立關聯，Rollup 彙總計算 | 單向／雙向關聯欄位建立關聯，查找引用彙總，公式可跨表整列引用 |
| 自動化 | 觸發：新增頁面、屬性變更、定期執行；動作：編輯屬性、通知、郵件、Webhook、Slack 等；付費方案功能，免費方案僅 Slack 通知類 | 觸發：新增記錄、修改記錄、到達記錄中的時間、定時等；動作：發送訊息、新增／修改／查找記錄等；各方案均可用，依方案有每月執行配額 |
| 權限顆粒 | 六個層級，單位為工作區、頁面與資料庫；資料庫專用層級中「可建立」屬 Business 與 Enterprise 方案 | 進階權限可對資料表、單筆記錄、單一欄位、檢視與儀錶板設定角色權限；屬專業版以上權益 |
| 單表容量 | 官方載明屬性上限 500 | 單表列數依方案：標準版與基礎版 2,000 列、專業版 2 萬列、旗艦版 5 萬列 |
表格裡的方案細節補完整。Base 的進階權限能做到「業務只能編輯自己名下的客戶、主管全表可讀」：記錄範圍支援「與本人相關」與自訂條件，也能管控複製、下載、建立副本等操作；依定價頁現值，進階權限屬專業版以上權益（2026-08-07 查核，以官方最新公告為準）。自動化的執行次數依方案有每月配額：標準版與基礎版各 1,000 次、專業版 5 萬次、旗艦版 50 萬次，按整個企業維度計算，到達上限後於次月 1 日起重新計算；啟用權限在表所有者或具可管理權限的同企業成員手上。單表列數上限同樣依方案：標準版與基礎版 2,000 列、專業版 2 萬列、旗艦版 5 萬列（2026-08-07 查核定價頁與站內列數擴容說明現值，以官方最新公告為準）。
誠實說，Base 的限制同樣存在：免費的標準版單表 2,000 列、自動化每月 1,000 次，進階權限要專業版以上。差別在於這些界線明列在定價頁上，導入前可以對著自己的資料量與流程數先算過，而不是上線後才發現踩線。判斷重心也很直接：需求核心在資料與流程（權限顆粒、配額、跨表協作），Base 這類線上資料庫是為此設計的；需求核心在筆記與文件編排，Notion 的頁面體驗仍是它的主場。
搬家怎麼做：Notion 匯出、Base 匯入
從 Notion 搬到 Base 走的是通用格式：Notion 官方支援把整頁資料庫匯出成 CSV（匯出文件），Base 官方支援匯入 .xlsx、.csv 與 .base（匯入規格），兩端接起來就是搬家的主幹道。步驟與坑如下：
- 挑資料庫：只搬需要活著繼續維護的表；純歷史紀錄留在原地封存即可，搬家範圍越小越快上線。
- 從 Notion 匯出：整頁資料庫會匯出為 CSV 檔，資料庫內的每個子頁面另存為 Markdown 檔，圖片與附件存成匯出包資料夾中的獨立檔案；表單檢視無法匯出，官方建議改用表格檢視操作（2026-08-07 查核）。
- 清一輪資料：狀態選項的寫法統一（之後才好轉成單選欄位）、日期格式一致、負責人名稱對齊 Lark 帳號使用的姓名。這一步在試算表裡做，比進了新系統再改省力。
- 匯入 Base：依官方規格，單次匯入上限 100 欄、20,000 列（筆記錄）、20 MB，另受方案權益限制，匯入後系統自動識別欄位型別；超過上限就分批或分表處理。
- 重建結構：CSV 是平面表格格式，Relation 與 Rollup 不會以關聯形式跟著過來。在 Base 用單向或雙向關聯欄位把表重新接起來、彙總改用查找引用；附件另行上傳到附件欄；原本寫在頁面內文的敘述，視需要貼回文字欄位或搬進雲端文件。把它當成「用通用格式搬資料、在新家重建結構」的工程來排，而非期待一鍵搬遷。
- 對數與收尾：新舊兩邊抽樣對筆數與關鍵欄位，確認無誤後公告舊庫唯讀封存，留一段雙軌期讓大家改習慣。
依我們協助台灣企業導入的經驗，結構單純的清單搬起來比多數人預期的快，真正花時間的是關聯重建與習慣切換；所以順序上先搬主表（客戶、專案）再搬從表（訂單、任務），分批進行。從試算表時代一路演進到自動化的完整節奏，另見從 Excel 到自動化的遷移時間軸。
不必急著搬的情況
留在 Notion 繼續用，對相當多團隊是合理的答案。個人知識庫、小團隊的筆記與文件協作，正是項目即頁面這個設計的主場；資料量離天花板還遠、權限需求單純的清單，也沒有搬的急迫性。「看膩了介面」不是搬家的理由，搬家總要付出重建結構與重養習慣的成本。
真正該啟動評估的訊號有跡可循：權限開始說不清楚（誰能看哪幾筆講不出口）、自動化需求撞上方案界線、單表筆數看得到天花板、或者同一份資料被拆成多個資料庫互相打架。出現兩個以上，就值得把資料拉出來試搬一張表。想用你們自己的資料驗證，預約顧問示範：身為 Lark 台灣授權代理商，艾瑞特資訊可以拿你們現行的 Notion 清單現場搭出 Base 雛形，欄位、關聯、權限與自動化一次設給你看，適不適合當場見真章。
常見問題
教學與評估過程最常被問的問題整理如下；Notion 部分以官方幫助中心為出處（2026-08-07 查核），Lark 部分以站內知識中心與定價頁現值為出處。
Q1：Notion 資料庫和一般表格有什麼不同？
Notion 資料庫是「頁面的集合」：官方定義中每一筆項目都是一頁可以打開編輯的頁面，屬性負責加上截止日、負責人這類結構化資訊，檢視則把同一份資料切換成表格、看板、時間軸等版面。一般表格的一列就只是一列，放不進完整的內文脈絡，這是兩者最根本的差別。
Q2：Notion 的 Relation 和 Rollup 有什麼差別？
Relation 用來在兩個資料庫的項目之間建立關聯，Rollup 用來在既有關聯上彙總對方的資料，官方文件載明 Rollup 以 Relation 為前提。常見組合是客戶與訂單兩個資料庫先用 Relation 接起來，再用 Rollup 在客戶頁面加總訂單金額或計算筆數；找不到 Rollup 資料來源時，先檢查關聯是否已建立。
Q3：Notion 免費方案可以用資料庫自動化嗎？
Notion 官方文件載明資料庫自動化屬付費方案功能：免費方案只能建立 Slack 通知類自動化，範本內建的自動化可以使用但不能編輯（2026-08-07 查核，以官方最新公告為準）。日常溝通不在 Slack 上的團隊，免費方案內實際可用的自動化相當有限，評估時要把這條界線算進去。
Q4：Notion 資料庫可以匯出成什麼格式？
Notion 的整頁資料庫可以匯出為 CSV 檔，資料庫內的每個子頁面另存為 Markdown 檔，圖片與附件會存成匯出包資料夾中的獨立檔案（2026-08-07 查核）。要注意表單檢視無法匯出，官方建議改用表格檢視操作；整個工作區也能從設定頁一次匯出。
Q5：什麼時候該考慮從 Notion 搬到 Lark Base？
從 Notion 搬到 Lark Base 的評估時機，是需求開始集中在系統級控管的時候：例如需要「同事只能看自己名下那幾筆記錄、特定欄位只開放主管」的權限顆粒、需要配額明確可估的自動化、或單表資料筆數已看得到天花板。Lark Base 的進階權限可切到單筆記錄與單一欄位（屬專業版以上權益），單表列數與自動化次數依方案明列於定價頁（2026-08-07 查核），導入前可以對著自己的量先算。
Q6：Notion 的資料搬到 Lark Base 要注意什麼？
Notion 資料搬到 Lark Base 走的是通用格式：Notion 匯出 CSV，Base 匯入 .csv 或 .xlsx，單次上限 100 欄、20,000 列（筆記錄）、20 MB，另受方案權益限制，匯入後系統自動識別欄位型別。要預留工的是結構重建：CSV 不帶跨表關聯，Relation 需在 Base 用關聯欄位重建、Rollup 改用查找引用，附件與頁面內文另行處理；建議先搬主表、留一段雙軌期。