SQLite和其他大部分現代SQL數據庫在基本設計目標上是不同的，它的目標是簡單。SQLite遵循這一目標，即使這樣偶爾會導致某些特性實現的低效化。下面列舉了SQLite的一些缺陷：
SQL-92特性方面
正如前面提到的，SQLite不支持SQL-92的在很多企業數據庫系統中可用的一些特性。
如：
外鍵約束（可解析的，但非強制）
很多ALTER TABLE特性
一些TRIGGER相關的特性
RIGHT和FULL OUTER JOIN
更新一個VIEW
GRANT和REVOKE
你可以在SQLite的主頁上獲取最新信息。
http://www.sqlite.org/omitted.html
http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql
低併發操作
SQLite只支持平面事務；它沒有嵌套和營救點能力。嵌套意味着在一個事務中可以有子事務的能力。營救點允許一個事務返回到前面已經到達的狀態。它沒有能力確保高層次事務的併發。它允許在單個的數據庫文件上多個併發的讀事務，但是隻能有一個排他的寫事務。這個侷限性意味着如果有事務在讀數據庫文件的一部分，所有其他的事務將被禁止寫該文件的任何一部分。類似的，如果有事務在寫數據庫文件的一部分，所有其他事務將被禁止讀或者寫該文件的任何一部分。
應用限制
因爲它事務處理的有限併發，SQLite只擅長處理小型的事務。在很多情況下，這不是問題。每個應用迅速的完成它的數據庫工作然後繼續前進，因此沒有一個事務會持有數據庫超過多少毫秒。但是在一些應用中，特別是寫入密集的，要求更多的併發的事務處理（表或者行級別的而不是數據庫級別的）那麼你將要爲該應用使用其他不同的DBMS。SQLite並不打算成爲一個企業DBMS。他最適合於實現，維護和管理的簡單性比商業數據庫的無盡複雜特性更爲重要的情況。
NFS問題
SQLite使用本地文件鎖原語來控制事務處理的併發性。如果數據庫文件駐留在網絡分區上，可能會導致文件鎖不能工作。很多的NFS實現被認爲在它們的文件鎖中是有bug的（在Unix和Windows上）。如果文件鎖不能像預計的一樣工作，那麼就可能會有兩個或兩個以上的應用程序在同時修改相同數據庫的同一部分，導致了數據庫的毀壞。因爲這個問題的出現是因爲位於下層的文件系統的實現的BUG，所以SQLite沒有辦法阻止它的發生
另一原因是大多數網絡文件系統的連接延時，效果不是很好。在這種環境下，在數據庫文件必須要跨網絡訪問的情況下，實現了客戶端-服務器的模型的DBMS會比SQLite更有效。
數據庫規模
因爲它的開發人員的開發設計選擇，SQLite可能不是一個做非常大型的數據庫好選擇。在理論上,一個數據庫文件文件可以有2TB（241）。日誌子系統的內存開銷和數據庫大小是成比例的。對每個寫事務，無論事務實際是寫是讀那個頁，SQLite爲每個數據庫頁維護一個內存內信息位。默認的頁大小是1024字節。即使如此，對一個有超過幾百萬頁的數據庫，內存開銷可能成爲一個嚴重的瓶頸。
對象的數目和類型
一個表或者索引被限制爲最多有264 – 1個項。當然，你不可能有這麼多的條目，因爲數據庫的241字節大小限制。在SQLite的當前的實現中，一個單獨的條目能夠持有230字節的數據。（下層的文件格式支持行大小相當於262字節的數據。）在打開一個數據庫文件時，SQLite會閱讀並且預處理來自主目錄表的所有條目並且創建很多內存目錄對象。所以，爲了最好的性能，最好控制表，索引，視圖和觸發器的數目。同樣雖然沒有限制表中列的數目，超過幾百列還是似乎太過的。只有表開始的31列是候選爲必然被優化的。你能夠在一個索引中儘可能加入列，但是有超過30列的索引將不會被用來優化。
宿主變量引用
在一些嵌入DBMS中，SQL語句能夠直接引用宿主變量（即來自應用程序空間的那些值）。在SQLite中這是不行的。作爲替代SQLite允許使用sqlite3_bind_* API函數來對輸入參數而不是輸出值綁定對SQL語句宿主變量。這種策略通常比直接的訪問策略更好，因爲後者需要特殊的預處理來將SQL語句轉化爲特殊的API調用。
存儲過程
很多DBMS有被稱爲存儲過程的能力來創建和存儲。存儲過程是形成邏輯作業單元和執行特殊任務的一組SQL語句。SQL查詢過程能夠使用這些過程。SQLite沒有這個能力。