SQLite 什麼時候夠用，什麼時候該換 PostgreSQL
很多人一開始聽到資料庫，就直覺覺得正式網站一定要用 MySQL 或 PostgreSQL，SQLite 好像只適合玩具專案。其實這種想法不太準確。對很多 Python 小型網站來說，SQLite 不只是可以用，而且常常是非常合理的第一步。重點不在於它是不是最強，而在於它是否符合你現在的規模與需求。 SQLite 最大的優點，就是簡單。它不...
很多人一開始聽到資料庫，就直覺覺得正式網站一定要用 MySQL 或 PostgreSQL，SQLite 好像只適合玩具專案。其實這種想法不太準確。對很多 Python 小型網站來說，SQLite 不只是可以用，而且常常是非常合理的第一步。重點不在於它是不是最強，而在於它是否符合你現在的規模與需求。
SQLite 最大的優點，就是簡單。它不需要另外啟動資料庫服務，不需要先建 server、建帳號、設權限，資料就是一個檔案。對內容站、教學站、個人工具站、小型後台來說，這種簡潔度非常有價值。你在 Flask 裡只要用 `sqlite3.connect()`，就能開始查詢與寫入資料。
例如像文章站最基本的資料表，通常只要幾個欄位就能開始：
id
title
author
content
created_at如果你的網站流量不大、寫入頻率不高、主要是單機運行，而且資料關聯不複雜，SQLite 很可能已經夠用了。它最適合的情境是：一開始先把產品做出來，而不是一開始就背很重的資料庫維運成本。
但 SQLite 也不是沒有邊界。當你開始碰到下面這些情況，就要開始考慮 PostgreSQL 或其他真正的資料庫服務了。
第一，併發寫入變多。SQLite 對讀取通常沒問題，但大量同時寫入時就比較容易出現瓶頸。
第二，資料模型越來越複雜。當你開始有比較多關聯、報表、進階查詢、索引需求，PostgreSQL 會更靈活。
第三，網站不再是單機。只要你開始拆成多台主機、多個 worker、容器化部署，SQLite 以單一檔案為中心的模式就不再那麼方便。
第四，你開始在意備份、遷移、權限與團隊協作。這些事情在 PostgreSQL 這種正式資料庫服務裡會比較標準化。
所以比較務實的想法是：如果你現在是第一個網站、內容站、小型後台，先用 SQLite 完全沒有問題。你真正需要警惕的不是「用 SQLite 很土」，而是你不知道什麼時候該升級。
比較好的策略通常是先把資料結構設計清楚，讓未來換資料庫時不至於太痛苦。也就是說，你可以先用 SQLite 快速上線，但心裡要知道當流量、複雜度與協作需求成長時，PostgreSQL 很可能會是下一步。