前言

租用主機就像買機車：你需要 24 小時擁有它，但實際使用時間可能只有幾小時。共享機車雖然方便，卻不一定在你需要的時刻有車。伺服器也是如此，傳統主機需要全時維護，而 serverless 提供按需計費的靈活性，讓你只為實際使用付費。這真的是更好的選擇嗎？讓我們從實際案例來探討。

計費方式

以row

目前使用 D1 與 turso，這種以 SQLite為技術核心以檔案為主體的，透過 http 遠端讀取，計算的方式主要以 row 資料筆數為單位，不要看他們動則用 M(百萬計算)以為很多。

Turso

最近為教會寫一個點名系統，8月剛上線，除了拉名單，寫入當天有出席的人，還有查詢，從月初到今天大約20天，使用量如下：

第一次看到有在使用的當天，可以到百萬的讀取，體感上很難接受，怎麼會這麼多.....，有列表功能的時候會超乎你的想像，但 Turso是有支援 transcation的，為何這樣說？因為D1沒有。

Cloudflare D1

這個是用在教會ATM奉獻之後，要填寫的表單，讀取主要是一些下拉選單，寫入則是送出表單的時候寫入資料庫。

CPU運算時間

我的 Blog就是使用 neon，作為桌機和筆電寫Blog的時候使用，是以 Postgres為技術核心，計算方式是以

CPU (vCPU) x 4 GB ram = 1 CU - hours
複製

從後台可以設定 cpu數量的上下限，並且他的 serverless 是當你沒有使用 超過 5分鐘，就會停止計算，所以算是每次請求低消5分鐘，但是我的 blog都只有寫文章和 build 靜態網頁(SSG)才會讀取，所以應該每寫一篇文章花5分鐘這樣，沒什麼太多經驗可以分享。

可以參考一下他的方案

Operation (By SQL Query)

這是我近期都在使用的 ORM Prisma 生態系推出的 Prisma Postgres，他是用 Prisma的 query來計算。

An operation is an action you take on your database, no matter the compute time. We count the Prisma ORM queries you make, not the SQL statements you run

這個從後端的 console 都可以看到，或是打開 prisma的開發模式，都可以看清楚每一筆 query的 raw sql，覺得是最容易理解的，但我也沒真的使用，可能最近公司會來用用看。

結論

身為客家工程師，遇到價格與技術時都很想知道每一分錢的極限在哪，維運是最容易被忽略的成本，有時候為了省一點錢，還需要多請專門的 SRE，特別在新創裡面，常常要後端工程師兼差SRE，現在評估的都是整體的成本，而非單一面向，不必太擔心 serverless 如果故障怎麼辦，你的 aws, gcp 是都不怕就是了(笑)，真的去使用和感受才能成為有用的經驗，這些是 AI 與 Vibe coding 不能給你的， 越去嘗試新的東西與真的玩過，給你的信心與肯定，在技術選擇上更加有把握，而非聽說。