為什麼我們需要ADO或JDO這類中介層？根本原因在於：數據庫查詢語言（SQL）並非程式設計語言的「本地語言」。SQL屬於高階宣告式語言，而應用程式使用的是命令式語言（如Java、C#）。這種語言範式的不匹配，迫使開發者引入API介面來橋接兩者。
在物件導向編程中，「相等」與「同一」是截然不同的概念。若兩個引用指向同一個記憶體位址，它們是「同一」物件；若兩個獨立物件擁有相同的成員值，它們則是「相等」物件。這區別在持久化層設計中至關重要。
Delphi的二進位表單檔案（.dfm）將控件物件序列化存儲，編譯時再反序列化還原到程式碼，這正是物件持久化的經典案例。專門定義可持久化物件的語言稱為ODL（Object Definition Language），它試圖解決物件模型與存儲模型的映射問題。
2002年解散的組織曾制定OQL（Object Query Language），但將其置入OO數據庫卻顯得多餘。因為「為了使用而建立的使用者與使用對象之間的抽象」——即介面導向程式設計——在OO數據庫中本來就不需要額外的查詢語言抽象層。
關係型數據庫時代，過程式語言的數據模式與關係模型尚能對應。但進入OO時代後，若仍用關係型數據庫，無異於「把車拆散存進車庫，明早再組裝開走」。車本身是邏輯完整的可運行整體，僅為存儲而拆解屬於不必要的抽象。
OO數據庫直接存儲物件實例，其數據模型邏輯與程式邏輯完全對應，省去了中間查詢語言層，可直接使用程式語言本地語法，並保證編譯期型別安全。反觀關係模式，查詢語句常以字串形式傳遞，雖有存儲過程等機制補救，但難以避免「數據庫存在程式中不存在的實例引用」等問題，唯有型別安全機制才能在編譯期捕獲未被引用的變量。
