Monday, March 28, 2005

Berkeley DB Btree vs SQLite Btree (contd)

Preliminary data indicates that SQLite does slightly better for tmpfs databases for writes and much better for reads. On normal disks, sqlite seems to do a whole lot better for writes. I'll post the test program in a couple of days. I noticed that the SQLite Btree take up only one third the size of Berkeley DB Btree on disk. That may explain the performance difference because the test program is I/O bound. Please note that these results are very preliminary, I am still learning the APIs.

Speaking about APIs, Berkeley DB is obviously well documented. For SQLite I had to go by the (well) commented source and a test program. Berkeley DB's transaction based API is a pain to use. Despite the lack of documentation, I found the SQLite API much more cleaner and simpler to use. In my next blog I'll present some numbers and the test program.

3 comments:

Anonymous said...

Ganesan, which version of sqlite are you using?? Just out of curiosity.

Gregory Burd said...

Hello, I'm the product manager for Oracle Berkeley DB and I'm happy to help you with your performance tests and analysis of them.

Take a look at what Mike Ownes (author of "The Definitive Guide to SQLite" says about Berkeley DB's SQL(ite) implementation on StackOverflow (http://stackoverflow.com/questions/2824135/how-fast-is-berkeley-db-sql-compared-to-sqlite).

moonsupport said...

If concurrency is a big deal, and you don't mind that bdb breaks under apache (or similar) unless you jump through hoops, then bdb is the way to go. Otherwise, sqlite is faster because it's simpler. Also the API is easier. For me, I use SQLite for most things, and Postgres if I care about transactions. Also, Oracle's business model apparently includes acquiring all open source projects until there's no choice but to use Oracle. What that says to me is that they are, internally, aware that they have no significant value-add, and thus must operate defensively.