Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
1–10 of 26 posts
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#2I'm not sure I get the point of this. Two of SQLites strong points (among many others) are:
(a) Short dependency list
(b) Platform independent filesystem storage
..doesn't this negate both of those for what seems like little gain?
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#3Is it faster? More reliable? A way to trick people into paying for SQLite?
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#4I'm not sure I get the point of this. Two of SQLites strong points (among many others) are: (a) Short dependency list (b) Platform independent filesystem storage ..doesn't this negate both of those for what seems like little gain?
BerkeleyDB doesn't have many dependencies, uses only plain files as storage, and is itself highly-portable open source (with a quasi-copyleft condition).
So you don't give up much to get the claimed benefits of this combination -- only the ability to use public-domain SQLite in proprietary distributed software.
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#5Is it faster? More reliable? A way to trick people into paying for SQLite?
The claims in the announcement email I received were performance-related:
- SQL Performance
-- 10s of thousands of INSERTS/UPDATES/DELETES per-second
-- 100s of thousands of SELECTs per-second
-- Approximately as fast as SQLite for reads (within 10%)
-- About 3X faster than SQLite for updates/writes
-- Has fine grained locking which leads to better read/write concurrency
-- 6-8x more transactions/second compared to SQLite when using multiple threads
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#6I'm not sure I get the point of this. Two of SQLites strong points (among many others) are: (a) Short dependency list (b) Platform independent filesystem storage ..doesn't this negate both of those for what seems like little gain?
Bad comparison. The point is that you interact with berkleyDB via an SQLite interface. It's just an interface layer in this case.
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#7I have nothing but good things to say about SQLite. Small. No dependencies. Lightning fast. Public domain. I use it exclusively for all things databases where the customer for whatever reason does not demand one of the other players. I'm glad to see a major actor in the DB industry picking up on it.
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#8I'm not sure I get the point of this. Two of SQLites strong points (among many others) are: (a) Short dependency list (b) Platform independent filesystem storage ..doesn't this negate both of those for what seems like little gain?
BerkeleyDB doesn't have many dependencies, uses only plain files as storage, and is itself highly-portable open source (with a quasi-copyleft condition). So you don't give up much to get the claimed benefits of this combination -- only the ability to use public-domain SQLite in proprietary distributed software.
SQLite outperforms it by far. That could also weigh in a little :)
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#9Earlier quoted context omitted.
BerkeleyDB doesn't have many dependencies, uses only plain files as storage, and is itself highly-portable open source (with a quasi-copyleft condition). So you don't give up much to get the claimed benefits of this combination -- only the ability to use public-domain SQLite in proprietary distributed software.
SQLite outperforms it by far. That could also weigh in a little :)
Do you have any benchmarks to support that claim?
Re: Oracle embraces SQLite; wraps it around BerkeleyDB as SQL API
#10Earlier quoted context omitted.
BerkeleyDB doesn't have many dependencies, uses only plain files as storage, and is itself highly-portable open source (with a quasi-copyleft condition). So you don't give up much to get the claimed benefits of this combination -- only the ability to use public-domain SQLite in proprietary distributed software.
SQLite outperforms it by far. That could also weigh in a little :)
I've used berkeley for hundreds of concurrent queries -- it is quite good in those situations, SQLlite is not -- its just not designed for those situations.
combining the two brings an easy interface that sqlite provide, and the concurrent performance that bdb has, is definitely providing value.