Google Sheets 當資料庫，可以撐到什麼時候？
先講一個可能違反直覺的事實：我們交付的系統裡，有相當比例的資料是存在 Google 試算表的，不是資料庫。
這常讓懂技術的朋友皺眉。但對中小企業來說，試算表有三個資料庫給不了的優勢。
為什麼刻意選試算表
第一，客戶看得懂、改得動。 系統壞掉的那天、或是我們不在的那天，客戶自己打開試算表就能看到所有資料、手動修一筆。這個「逃生出口」的價值，在真的出事時才會體現。
第二，零維運成本。 不用管伺服器、不用付月費、不用擔心備份——Google 幫你處理。對一年營運預算有限的公司，這件事很實際。
第三，天生就有權限與紀錄。 誰在什麼時候改了哪一格，版本記錄查得到。這在爭議發生時是免費的稽核軌跡。
一般的系統長什麼樣
以我們常見的架構為例，試算表通常擔任最底層的「資料層」：
它的極限在哪：三個真實的天花板
天花板一：讀寫速度。 試算表的 API 有配額限制，每分鐘的讀寫次數是有上限的。一般中小企業的日常操作遠遠碰不到，但如果你的系統會每秒被打好幾次（例如公開網站的即時查詢），就會開始遇到延遲或被限流。
天花板二：資料量。 單一試算表的儲存格總數有上限。實務上，當單一分頁超過數萬列，開啟速度就會開始明顯變慢，人用起來會痛。
天花板三：同時寫入。 兩個流程同一瞬間要寫最後一列，有機率互相覆蓋。這在低頻使用下幾乎不會發生，但頻率一高就會變成偶發的「資料不見了」——而且極難重現、極難查。
實務上我們用三個問題決定：
- 一天的寫入次數會超過幾百次嗎？ 不會 → 試算表沒問題
- 會不會有多人同一秒寫同一張表？ 不會 → 試算表沒問題
- 資料會不會在一年內累積到數萬列？ 不會 → 試算表沒問題
三個都是「不會」，就用試算表，把省下的預算花在流程設計上——那才是真正決定系統好不好用的地方。
要搬家的時候，怎麼搬才不痛
如果哪天真的碰到天花板，好消息是：只要一開始欄位設計乾淨，搬家不難。我們的作法是從第一天就把試算表當資料庫用：
- 每一列有唯一的 ID，不靠列號當身分（列號會因為刪列而漂移）
- 欄位固定位置、固定型別，不在資料區塞備註
- 程式讀寫一律透過同一層封裝，換底層時只改那一層
做到這三件事，從試算表換到真正的資料庫，改的是資料存取層，不是整套系統。
一句話總結
技術選型沒有標準答案，只有適不適合。用資料庫做一個客戶不敢碰的系統，不見得比用試算表做一個客戶天天在用的系統有價值。