我們的看法是：AppSheet 撐得住企業的部門級流程，前提是控制每個使用者同步到手機的資料量，以及 App 裡資料表的數量與大小。Google 官方寫明，一個 App 存在手機上的所有資料，壓縮後上限是 5MB 或 10MB（依裝置而定），試算表不要超過 10 萬列或 1,000 欄；而且效能通常在碰到上限之前就先變慢。所以評估 AppSheet 企業應用，該問的不是「總共有幾筆」，而是「每個人要下載多少、每次同步要讀幾張表」。
AppSheet 適合哪些企業應用？
它的價值不在取代 ERP 或 CRM，而在補上「Excel 已經不夠用，但還不值得開一個專案」的那段空檔：
- 中小企業：庫存、訂單、客戶資料還放在 Google Sheets 的，可以先做成手機 App，讓外勤人員現場回報。
- 大型企業的部門級工具：設備巡檢、請假加班簽核、業務拜訪紀錄、盤點。需求急、規格常變，不值得排進 IT 的開發時程。
- 現場資料收集：拍照、GPS 位置、簽名都有內建的欄位型別；條碼掃描是欄位上的設定，需要 Core 以上方案，而且只能在手機 App 使用。
- 離線作業：官方說明 App 沒有網路也能用，但第一次要在有網路時開啟、把資料下載到手機；網路差的現場可以開「延遲同步」（Delayed sync），回到有網路的地方再同步。
AppSheet 資料量上限是多少？三個常見迷思
評估時最常聽到的問題是「我有 10 萬筆資料，跑得動嗎？」下面三個迷思，對照的都是 Google 官方說明：
| 迷思 | 官方怎麼寫 | 實務上怎麼做 |
|---|---|---|
| 上限看總筆數 | 上限是「一個 App 存在手機上的所有資料」壓縮後 5MB 或 10MB；圖片與文件不計入 | 控制每個人下載的量，而不是總量 |
| Google Sheets 免費又無限 | 試算表不要超過 10 萬列或 1,000 欄；Google 試算表本身上限 2,000 萬個儲存格或 100MB | 資料量會長大的表，一開始就評估改用資料庫 |
| 同步慢是手機網路太慢 | 最常見的原因是資料表的數量與大小，雲端資料來源的延遲通常是最大因素；離 AppSheet 伺服器較遠的地區，裝置到伺服器的延遲也會明顯拖慢；虛擬欄位太多同樣會拖慢 | 先刪不必要的資料與資料表，再減少虛擬欄位 |
官方也提醒，壓縮後的大小很難換算成列數（空白儲存格多的大表反而好壓縮），所以「幾萬筆會慢」沒有標準答案，要用編輯器裡的效能分析器（performance analyzer）實際量。
AppSheet Database 和 Google Sheets 怎麼選？
資料放哪裡，決定了 App 能長到多大。三種常見來源的差別：
| 資料來源 | 官方限制 | 安全篩選怎麼運作 | 適合 |
|---|---|---|---|
| Google Sheets | 建議不超過 10 萬列或 1,000 欄 | 先讀完整張表，再過濾要送到手機的資料 | 入門、資料量小 |
| AppSheet Database | 每個資料庫：Free 1,000 列、Starter 與 Core 2,500 列、Enterprise Plus 20 萬列（可洽業務調高）；每庫 20 張表、每表 100 欄 | 可轉成資料庫查詢 | 不想自己架資料庫、量中等 |
| MySQL、PostgreSQL、SQL Server、BigQuery | 依資料庫本身；需要 Enterprise Plus 方案才能連接 | 簡單條件可轉成 SQL 查詢，官方說可處理「millions of database records」 | 資料量大、要長期擴充 |
最容易被忽略的是第三欄：資料放在 Google Sheets 時，伺服器仍要先讀完整張表；換成資料庫，篩選條件才能直接變成查詢。
另外，AppSheet Database 各方案都能用，不是 Enterprise 才有；但 Core 方案每個資料庫只有 2,500 列，連接外部資料庫又需要 Enterprise Plus。我們的看法是：資料量會持續長大的正式應用，從一開始就要把方案算進成本。
AppSheet 效能優化怎麼做？
AppSheet 效能優化有四個方向，前兩個處理「下載多少」，後兩個處理「讀多少、算多少」。
1. 安全篩選：每個人只下載自己的資料
安全篩選（Security Filters）是逐列判斷的條件，結果為真的那一列才會送到手機，需要 Core 以上方案。例如設定 [業務Email] = USEREMAIL()，業務只會下載指派給自己的客戶。
兩個常被搞錯的地方：
- 切片（Slice）不能取代安全篩選。官方說明切片會先把全部資料下載到手機再過濾，安全篩選則是只送符合條件的資料。
- 安全篩選不是完整的權限控管。官方原文寫明它「aren’t a complete security solution」，敏感資料仍要在資料來源那一層保護。
接資料庫時，條件寫得越簡單越好。官方列出能轉成 SQL 查詢的寫法是欄位與固定值比較（=、<、>、<=、>=）、IN()，以及用 AND() 串起來的組合。NOT()、OR() 在 MySQL 這類資料庫多半無法轉換，資料一多就會變慢；但官方註明 AppSheet Database 與 BigQuery 可以使用。
2. 資料分割：同一張表拆成多個來源
想留在試算表，可以用官方的「資料分割」（data partitions）：把同一張表拆到多個工作表或檔案，再用 USEREMAIL() 決定每個人讀哪一份。這個功能需要 Enterprise Plus 方案；代價是報表與維護變複雜，每一份的欄位結構也必須完全一致。
3. 同步設定：讓使用者不必乾等
在編輯器的 Settings > Offline mode 與 Performance 裡：
- 唯讀的參考資料（產品清單、門市清單）設成唯讀並開啟伺服器快取，官方說明伺服器最多快取 5 分鐘；這個功能需要 Core 以上方案。
- 「自動更新」與「延遲同步」可以同時開，官方標為「Best for most use cases」：修改先存在手機，有網路時在背景同步。但同步間隔越久，越容易和別人的修改衝突。
4. 混合架構：複雜計算交給 Apps Script
如果需求是「介面簡單、計算複雜」，例如報價試算、排程，與其在 AppSheet 裡堆虛擬欄位，不如交給 Google Apps Script：
- 使用者在 App 輸入資料。
- 自動化的 Bot 用「Call a script」任務呼叫 Apps Script 函式（需要 Core 以上方案）。
- Apps Script 在 Google 伺服器端計算，把結果寫回資料表。
- 同步後在 App 上顯示結果。
三個實作細節：
- 只支援獨立的 Apps Script 專案，不支援綁在試算表上的腳本。原本寫在試算表裡的腳本，要先搬成獨立專案。
- AppSheet 改到的資料不會觸發 Google Sheets 的 onEdit。原本靠 onEdit 跑的邏輯，要改成定時觸發或由 Bot 直接呼叫。
- 可以勾選「Run asynchronously」讓腳本在背景跑，回應會比較快；但如果 App 需要在同步完成前拿到腳本改好的資料，就不能非同步，官方提醒否則可能得到錯誤結果。
另外兩個習慣是官方「Remove unnecessary data」原則的延伸：不再變動的歷史資料定期移到 App 沒連接的表；寫入後就不變的值（例如訂單總額）存成實體欄位，不要每次同步都用虛擬欄位重算。
照做還是慢？把效能分析器的截圖寄來，我們回你卡在哪張表、該照本文調整，還是該換系統。
AppSheet 缺點：什麼時候該換成客製系統？
AppSheet 補空檔很強，但出現下面三個訊號時，繼續留在上面會愈來愈貴：
| 訊號 | 為什麼 |
|---|---|
| 授權跟著人數增加 | 官方寫明，組織裡的 App 只要有人存取就會占用一份授權，用過後到當月底都歸這個人。Google Workspace 有些版本已含 AppSheet Core，但要接外部資料庫或用較大的資料庫上限，就需要 Enterprise Plus |
| 邏輯越來越複雜 | 跨表條件運算、多階簽核、需要交易保證的流程，做得出來，但難測試、難交接，改一處容易牽動別處 |
| 要跟別的系統對接 | 自動化可以呼叫 webhook，但要串既有 ERP、電商平台、金流，認證、錯誤重試與對帳通常還是要寫程式 |
這三個訊號出現得愈多，客製化愈划算。從 Excel 走到客製系統的完整判斷，見〈Excel 管理撐不住了？〉。
我們怎麼做？
初步判讀不收費：寫信告訴我們現在的資料放在哪裡、大約幾筆、幾個人要用、最慢的是哪個畫面，我們回你該優化還是該換系統。
接下來分兩個階段。第一階段是顧問諮詢，單獨報價：盤點流程、挑出要上 App 的步驟，把流程寫成 SOP 與需求單；交付的文件歸你所有，拿去給其他廠商比價也可以。文件確認後，第二階段才報執行價。流程還在變的，第二階段可以先用 AppSheet 做一版讓同仁實際用用看，我們做過這類輕量表單流程；跑順了再決定要不要寫成正式系統。
服務內容見企業系統客製開發。App 以外的匯出、對帳、通知要接起來，見AI 流程自動化；通知要發到 LINE，見LINE 官方帳號整合。
常見問題
AppSheet 可以處理多少資料量？
Google 官方寫明，一個 App 存在手機上的所有資料，壓縮後上限是 5MB 或 10MB（依裝置而定），試算表不要超過 10 萬列或 1,000 欄。AppSheet Database 每個資料庫的上限依方案而定：Core 2,500 列、Enterprise Plus 20 萬列。資料量再大，要改接 MySQL、PostgreSQL 這類資料庫，這需要 Enterprise Plus 方案，並讓安全篩選能轉成資料庫查詢。
AppSheet 同步很慢怎麼辦？
先用編輯器裡的效能分析器找出慢在哪張表。官方說明同步慢最常見的原因是資料表的數量與大小，虛擬欄位太多也會拖慢。對策是刪掉不必要的資料、設定安全篩選、減少虛擬欄位，不常變動的參考表設成唯讀並開啟伺服器快取。
AppSheet Database 和 Google Sheets 差在哪？
Google Sheets 適合入門與小量資料，官方建議不要超過 10 萬列或 1,000 欄，而且安全篩選要等整張表讀完才過濾。AppSheet Database 是內建的資料庫，免設定、官方說明效能較好，但每個資料庫有列數上限（Core 2,500 列、Enterprise Plus 20 萬列）。
AppSheet 可以搭配 Apps Script 嗎？
可以。在自動化的 Bot 裡加入「Call a script」任務呼叫 Apps Script 函式，需要 AppSheet Core 以上方案，而且只支援獨立的 Apps Script 專案，不支援綁在試算表上的腳本。另外，AppSheet 改到的資料不會觸發 Google Sheets 的 onEdit，要改用定時觸發或由 Bot 直接呼叫。
AppSheet 適合用來做 ERP 嗎？
不適合當核心帳務系統。AppSheet 適合做 ERP 的延伸：現場資料收集、巡檢、盤點、簽核這類周邊流程；財務與庫存的主帳仍應留在正式的 ERP。
本文引用資料來源
- 資料量與效能：Limits on data size、Improve the speed of Sync、App performance: Core concepts、Monitor app performance using the performance analyzer
- 安全篩選與同步：Scale using security filters、Scale using data partitions、Use virtual columns、Offline and Sync: The Essentials
- 資料來源與方案：What is an AppSheet database?、AppSheet databases：Restrictions, limits, and known issues、Use data from Google Sheets、AppSheet 方案與功能比較、About licensing in AppSheet for organizations
- Apps Script：Call Apps Script from an automation
- Google 雲端硬碟說明：Files you can store in Google Drive（試算表 2,000 萬個儲存格或 100MB）