如果你有許多的客戶端程序要通過網絡訪問一個共享的數據庫, 你應當考慮用一個客戶端/服務器數據庫來替代SQLite. SQLite可以通過網絡文件系統工作, 但是因為和大多數網絡文件系統都存在延時, 因此執行效率不會很高. 此外大多數網絡文件系統在實現文件邏輯鎖的方面都存在著bug(包括Unix 和windows). 如果文件鎖沒有正常的工作, 就可能出現在同一時間兩個或更多的客戶端程序更改同一個數據庫的同一部分, 從而導致數據庫出錯. 因為這些問題是文件系統執行的時候本質上存在的bug, 因此SQLite沒有辦法避免它們.

經驗告訴我們, 應該避免在許多計算機需要通過一個網絡文件系統同時訪問同一個數據庫的情況下使用SQLite.

2.高流量網站

SQLite通常情況下用作一個網站的后臺數據庫可以很好的工作. 但是如果你的網站的訪問量大到你開始考慮采取分布式的數據庫部署, 那么你應當毫不猶豫的考慮用一個企業級的客戶端/服務器數據庫來替代SQLite.

3.超大的數據集

當你在SQLite中開始一個事務處理的時候(事務處理會在任何寫操作發生之前產生, 而不是必須要顯示的調用BEGIN...COMMIT), 數據庫引擎將不得不分配一小塊臟頁(文件緩沖頁面)來幫助它自己管理回滾操作. 每1MB的數據庫文件SQLite需要256字節. 對于小型的數據庫這些空間不算什么, 但是當數據庫增長到數十億字節的時候, 緩沖頁面的尺寸就會相當的大了. 如果你需要存儲或修改幾十GB的數據, 你應該考慮用其他的數據庫引擎.

4.高并發訪問

SQLite對于整個數據庫文件進行讀取/寫入鎖定. 這意味著如果任何進程讀取了數據庫中的某一部分, 其他所有進程都不能再對該數據庫的任何部分進行寫入操作. 同樣的, 如果任何一個進程在對數據庫進行寫入操作, 其他所有進程都不能再讀取該數據庫的任何部分. 對于大多數情況這不算是什么問題. 在這些情況下每個程序使用數據庫的時間都很短暫, 并且不會獨占, 這樣鎖定至多會存在十幾毫秒. 但是如果有些程序需要高并發, 那么這些程序就需要尋找其他的解決方案了。