Here's the thing though. The current implementation of CDBBatch and CDBWrapper (which you have to adapt after you replace the database) only understand
key and value data, there is no concept of primary keys or tables or any other SQL-specific stuff in it. And since Key and Value types are exposed in an API, it is impossible to drop-in an SQL database in it without changing the rest of the codebase that uses the database wrapper.
The only thing the software uses the "database" for is as a disk backed hashtable. Thus the only interface the software needs or even remotely makes sense to use is a key,value interface. There wouldn't be any "primary keys or tables or any other SQL-specific stuff in it" because the software has no use for anything like that, and the database wrapper can use whatever is suitable for the backend.
You can backend that interface with anything you like, and other people have substituted other things into it (including sql databases). If you google around you can find some of these failed experiments. (Failed because the performance was extremely poor)