自90年代末以來，數據庫系統激增。盡管當時的選擇相對較少，但現在有數百種數據庫系統可供選擇，涵蓋了不同的架構、API、模型等。本文將對嵌入式和客戶端/服務器兩種數據庫系統架構進行比較和對比。

在這些體系結構中，你可以找到各種類型的數據庫系統:

關系型/SQL

分層

網絡模型（層次結構的超集）

圖形數據庫（網絡模型的超集）

NoSQL

NewSQL

Columnar

內存/持久/混合

等等。

即使是NoSQL也包含了一系列的模型、文檔、鍵/值、寬列等。

嵌入式數據庫系統的關鍵區別在于，它們與應用程序緊密集成，提供本地數據存儲，而不依賴于單獨的數據庫服務器。換句話說，數據庫功能被編譯并與應用程序代碼鏈接，這樣應用程序就可以直接調用數據庫系統，就像它調用宿主語言庫的標準函數（例如標準C庫）一樣。這消除了執行路徑中的進程間通信以及由此帶來的所有延遲。

消除客戶端/服務器負擔還可以減少數據庫系統的代碼大小和資源消耗需求。結果是一個更小、更快的數據庫系統。這使得嵌入式數據庫系統更適合資源受限的嵌入式系統。然而，請注意，“嵌入式數據庫”一詞與“嵌入式系統”一詞完全無關。

嵌入式數據庫系統至少從80年代早期就已經出現了，遠遠早于嵌入式系統擁有足夠的處理能力來利用任何類型的數據庫系統。8位和16位嵌入式系統無法尋址足夠的內存，所以直到90年代后期基于32位處理器的嵌入式系統變得普遍，嵌入式數據庫系統才開始在嵌入式系統中使用。

因此，嵌入式數據庫系統產生于在Windows、Unix和類Unix系統上為一系列業務應用程序提供數據庫支持的需求。

嵌入式數據庫系統的嵌入式特性限制了它們的可擴展性。但是，考慮到用例，這并不是一個問題。由于沒有進程間通信，共享數據庫的所有并發任務都存在于一個系統中，并且可以在單個系統上啟動的進程和/或線程的數量存在固有的限制，即使是具有數十個內核和數百或數千GB內存的相對較大的Linux系統。

相比之下，在強大的服務器上托管的客戶機/服務器數據庫系統可以有10個、100個或1000個連接到數據庫服務器并請求數據庫系統的CRUD(創建、讀取、更新、刪除)服務的其他系統。這些系統需要能夠比嵌入式數據庫系統更大程度地擴展。

客戶端和服務器的分離還可以提高整個系統的安全性/可靠性。因為嵌入式數據庫與應用程序相鏈接，所以它們共享相同的地址空間。這使得錯誤的應用程序有可能破壞數據庫或嵌入式數據庫系統運行時，或者同時破壞兩者。

通過獨立的客戶端和服務器進程，操作系統可以將數據庫服務器與惡意應用程序隔離開來。客戶端進程也可能運行在完全獨立的系統中，進一步將它們與數據庫服務器隔離開來。

嵌入式數據庫比客戶機/服務器數據庫更容易部署和維護。嵌入式數據庫系統只是應用程序安裝過程中的一部分。客戶機/服務器數據庫系統必須單獨安裝，通常安裝在單獨的服務器上。還必須對其進行配置，以提高可伸縮性。這通常需要數據庫管理員(DBA)的參與。

有一種說法認為客戶端/服務器數據庫擅長復雜的操作/事務，但嵌入式數據庫系統中通常沒有任何固有的東西可以阻止它們執行同樣復雜的操作。當然，SQL語言的覆蓋范圍的完整性以及SQL引擎優化器的質量存在差異，但客戶端/服務器和嵌入式數據庫系統都是如此。嵌入式數據庫系統只提供原生的、非SQL的、API，這使得在不同表的列上實現與排序、過濾和聚合等同的多目標聯接變得困難和/或不切實際。

總之，為了簡單、資源效率和本地數據存儲，選擇嵌入式數據庫。選擇可擴展性和集中管理至關重要的客戶端/服務器系統。