在Subversion的初始設計階段，開發者因為多種原因而決定采用Berkeley DB，比如它的開源協議、事務支持、可靠性、性能、簡單的API、線程安全、支持游標等。
Berkeley DB提供了真正的事務支持－這或許是它強大的特性，訪問你的Subversion版本庫的多個進程不必擔心偶爾會破壞其他進程的數據。事務系統提供的隔離對于任何給定的操作，Subversion版本庫代碼看到的只是數據庫的靜態視圖－而不是一個在其他進程影響不斷變化的數據庫－并能夠根據該視圖作出決定。如果該決定正好同其他進程所做操作沖突，整個操作會回滾，像什么都沒有發生一樣，并且Subversion會優雅的再次對更新的靜態視圖進行操作。
Berkeley DB另一個強大的特性是熱備份－不必“脫機”可以備份數據庫環境的能力。（備份問題在本文暫不討論）
Berkeley DB同時是一個可信賴的數據庫系統。Subversion利用了Berkeley DB可以記日志的便利，這意味著數據庫先在磁盤上寫一個日志文件，描述它將要做的修改，然后再做這些修改。這是為了確保如果如果任何地方出了差錯，數據庫系統能恢復到先前的檢查點—一個日志文件認為沒有錯誤的位置，重新開始事務直到數據恢復為一個可用的狀態。關于Berkeley DB日志文件的更多信息可以參考svn中文使用說明中的“管理磁盤空間”一節。
但是每朵玫瑰都有刺，我們也必須記錄一些Berkeley DB已知的缺陷。首先，Berkeley DB環境不是跨平臺的。你不能簡單的拷貝一個在Unix上創建的Subversion版本庫到一個Windows系統并期望它能夠正常工作。盡管Berkeley DB數據庫的大部分格式是不受架構約束的，但環境還是有一些方面沒有獨立出來。其次，使用Berkeley DB的Subversion不能在95/98系統上運行—如果你需要將版本庫建在一個Windows機器上，請裝到Windows2000或WindowsXP上。另外，Berkeley DB版本庫不能放在網絡共享文件夾中，盡管Berkeley DB承諾如果按照一套特定規范的話，可以在網絡共享上正常運行，但實際上已知的共享類型幾乎都不滿足這套規范。
后，因為Berkeley DB的庫直接鏈接到了Subversion中，它對于中斷比典型的關系型數據庫系統更為敏感。大多數SQL系統，舉例來說，有一個主服務進程來協調對數據庫表的訪問。如果一個訪問數據庫的程序因為某種原因出現問題，數據庫守護進程察覺到連接中斷會做一些清理。因為數據庫守護進程是訪問數據庫表的進程，應用程序不需要擔心訪問許可的沖突。但是，這些情況與Berkeley DB不同。Subversion（和使用Subversion庫的程序）直接訪問數據庫的表，這意味著如果有一個程序崩潰，會使數據庫處于一個暫時的不一致、不可訪問的狀態。當這種情況發生時，管理員需要讓Berkeley DB恢復到一個檢查點，這的確有點討厭。除了崩潰的進程，還有一些情況能讓版本庫出現異常，比如程序在數據庫文件的所有權或訪問權限上發生沖突。因為Berkeley DB版本庫非常快，并且可以擴展，非常適合使用一個單獨的服務進程，通過一個用戶來訪問—比如Apache的httpd或svnserve（可以參考svn中文使用說明中的 配置服務器）—而不是多用戶通過file:///或svn+ssh://URL的方式多用戶訪問。如果將Berkeley DB版本庫直接用作多用戶訪問，可以參考svn中文使用說明中的“支持多種版本庫訪問方法”一節。
FSFS
在2004年中期，另一種版本庫存儲系統慢慢形成了：一種不需要數據庫的存儲系統。FSFS版本庫在單一文件中存儲修訂版本樹，所以版本庫中所有的修訂版本都在一個子文件夾中有限的幾個文件里。事務在單獨的子目錄中被創建，創建完成后，一個單獨的事務文件被創建并移動到修訂版本目錄，這保證提交是原子性的。因為一個修訂版本文件是持久不可改變的，版本庫也可以做到熱備份，象Berkeley DB版本庫一樣。
修訂版本文件格式代表了一個修訂版本的目錄結構，文件內容，和其它修訂版本樹中相關信息。不像Berkeley DB數據庫，這種存儲格式可跨平臺并且與CPU架構無關。因為沒有日志或用到共享內存的文件，數據庫能被網絡文件系統安全的訪問和在只讀環境下檢查。缺少數據庫花消同時也意味著版本庫的總體體積可以稍小一點。
FSFS也有一種不同的性能特性。當提交大量文件時，FSFS使用O(N)算法來追加條目，而Berkeley DB則用(N^2)算法來重寫整個目錄。另一方面，FSFS通過寫入與上一個版本比較的變化來記錄新版本，這也意味著獲取新修訂版本時會比Berkeley DB慢一點，提交時FSFS也會有一個更長的延遲，在某些極端情況下會導致客護端在等待回應時超時。
重要的區別是當出現錯誤時FSFS不會楔住的能力。如果使用Berkeley DB的進程發生許可錯誤或突然崩潰，數據庫會一直無法使用，直到管理員恢復。假如在應用FSFS版本庫時發生同樣的情況，版本庫不會受到任何干擾，壞情況下也是會留下一些事務數據。
真正對FSFS不利的是相對于Berkeley DB的不成熟，缺乏足夠的使用和壓力測試，許多關于速度和可擴展性的判斷都是建立在良好的猜測之上。在理論上，它承諾會降低管理員新手的門檻并且更加不容易發生問題。在實踐中，只有時間可以證明。
總之，這兩個中并沒有一個是更正式的，訪問版本庫的程序與采用哪一種實現方式無關。通過上文和下表（從總體上比較了Berkeley DB和FSFS版本庫），讀者可以自行選擇自己需要的存儲方式
| 特性 | Berkeley DB | FSFS |
|---|---|---|
| 對操作中斷的敏感 | 很敏感；系統崩潰或者權限問題會導致數據庫“塞住”，需要定期進行恢復。 | 不敏感。 |
| 可只讀加載 | 不能 | 可以 |
| 存儲平臺無關 | 不能 | 可以 |
| 可從網絡文件系統訪問 | 不能 | 可以 |
| 版本庫大小 | 稍大 | 稍小 |
| 可擴展性：修訂版本樹的數量 | 數據庫，沒有限制 | 許多古老的本地文件系統在處理單一目錄包含上千個條目時出現問題。 |
| 可擴展性：文件較多的目錄 | 較慢 | 較快 |
| 速度：檢出新的代碼 | 較快 | 較慢 |
| 速度： 大的提交 | 較慢，但是時間被分配在整個提交操作中 | 較快，但是后較長的延時可能會導致客戶端操作超時 |
| 組訪問權處理 | 對于用戶的umask設置十分敏感，好只由一個用戶訪問。 | 對umask設置不敏感 |
| 功能成熟時間 | 2001年開始使用 | 2004年開始使用 |
