Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I agree with Osama that you should compare the features your after first.</p> <p>However, I disagree that "complicated" data should automatically drive you toward sqlite. While I haven't seen any benchmarks (nor have cared to write any), I have a gut reaction (whatever that's worth) that says BerkeleyDB is going to outperform nearly every time.</p> <p>That said. I don't think that's what I'd use to make my own decision. It goes back to those features. If all I want is a simple data store, then I'd probably choose sqlite because its going to be easier. Likewise, if I want to be able to arbitrarily query my data on any field, or possibly one day store it in an "enterprise" SQL database, I'd likely go with sqlite because future migration will be easier. If, however, I intend to move beyond a simple data store, and am eyeing transactional safety, high concurrency, high availability, having many readers <em>and</em> writers, etc <em>and</em> I have a set of fairly well-defined "queries", then I probably want BDB.</p> <p>Notice that "complexity" of my data doesn't really enter into these equations. The reason is simple. BDB can hold my object in it's native serialized format. Sql of any flavor comes with the famous impedence mismatch which, IMO, complicates my <em>application</em>.</p> <p>If you are seriously considering BDB, I need to warn you that you should decide the type of storage your going to use <em>up front</em> as the different types of stores that BDB offers are not necessarily compatible.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload