Greg, Thanks for the explanation. So it's Sleepycat license, ok, but we still can't use it in an application with proprietary code, right?
It would be interesting to track the progress of SQLite/BDB. Roger Binns has noted some important issues, but granted those are solved, would you say SQLite/BDB is going to be an acceptable solution as an in-process server-side database? Is there a vision how BDB, now with SQLite, fits into the family of Oracle's products? Clearly it's far from Oracle Database, but do you foresee competition with MySQL team? Just asking :) Igor Gregory Burd-2 wrote: > > Hello, > > My name is Greg, I'm one of the product managers within Oracle working on > the Berkeley DB products. I joined Oracle when Sleepycat was acquired but > I've been working on BDB for nearly nine years now. I was the one who > pushed hard to integrate SQLite and BDB, I think the two products go well > together without damaging either one. I am also the guy responsible for > most of the messaging on the Oracle.com website (with a lot of editing > oversight and marketing input), so if you want to question something there > please just email me. > > We here in the Berkeley DB team within Oracle's Embedded Database group > are thrilled to have Oracle join the SQLite Consortium. Today and in the > past our goal with open source collaborations has been to work closely > together, help each other out, keep things informal-yet-formal, and give > credit where credit is due. The SQLite product is excellent, we don't > want or need to fork it. The SQLite3 ANSI C API is like the BDB ANSI C > key/value API, de-facto standards in their respective spaces. From our > view this combination is like chocolate and peanut butter, two great > products that go well together. Some will like this combo and find value > in it, others won't. That's okay, in fact it's the way it should be. We > are thrilled to be joining this community, we're not the enemy or the > competition. > > Clearly there are going to be many questions, I'm here to help answer them > as best I can. > > > License: Oracle Berkeley DB is not licensed under the GPL. Berkeley DB is > released under the terms of the Sleepycat License. The Sleepycat License > is significantly different from the GPL, take a look. > http://en.wikipedia.org/wiki/Sleepycat_License > > Compatibility: "... [the] application-level behavior of the two products > is identical..." Okay, this is a bit of an overstatement at this point > and I freely admit that. This is our long-term goal, so I think it's fair > to put have it on our site. Basically we're telling people that we'd like > to be as close to 100% drop-in compatible as possible while still > providing the unique value of Berkeley DB as a btree storage engine. For > our first release, I think you'll have to admit that we are very close to > the mark. We're already nearing a patch release and it is even closer. > This will evolve, both SQLite and BDB's SQL will benefit along the way. > > Comparison: "... improved performance, concurrency, scalability, and > reliability." Fundamentally, we are faster because we don't lock the > entire database on writes as SQLite's btree does. BDB is designed for > concurrent multi-process/thread access, this gives us a speed advantage > when there is any concurrency in the system. Single-threaded performance > is a more apples-to-apples comparison and this is more evenly matched. > The product is evolving fast, we're constantly finding ways to use > advanced features in BDB for special cases in SQLite. Again, we're only > just in release 1 of the combined product and we're already in very good > shape to be faster in general. > > MVCC: We're going to add in support for MVCC (snapshot isolation), it's > not there in the first release. This will continue to help speed up > concurrent access and prevent deadlocks. > > HA: Clearly we're going to integrate (in a SQLite-friendly way) support > for HA/replication. It's not there in this release. If you have ideas > for how to properly make this fit into the product let us know! Should it > be a PRAGMA? Should it be C-functions? Something else? Speak up now. > > Compaction: We punted on compaction in the first release because we wanted > to do it using BDB's built-in compaction code (which can compact the > database and optimize the btree while it's being used, it can even do this > a little bit at a time so as not to be overly disruptive). We didn't get > this into the code line in time for the first release, it's coming very > soon. > > Compression: BDB has support for compression of things stored in the > database, this is something we hope to integrate into the SQL API very > soon. > > Encryption: Again, we are hard at work on this. BDB already supports > encrypted databases, so it won't be hard to do. > > > We are also working on a comparison paper with Mike Owens (of "The > Definitive Guide to SQLite" fame). We hope to get this finished very soon > and make it available for comment. Mike is doing a great job of really > providing a critical view of our combined product, which is exactly what > we want. > > There is a lot more we're working on, we're focused on a number of > improvements in BDB itself and in our adaptor layer between BDB and > SQLite. What's great about this is that for fifteen years we had avoided > SQL and just focused on being the best transactional storage engine around > and I'd say we did a pretty good job of that. Now we can happily join > forces with a great community focused on the SQL piece. SQLite does an > amazing job of providing the features of a relational database and SQL92 > in a stunningly small package, we hope to add our world-class btree > storage layer and experience to that package. > > We believe that this is good news for everyone, I hope you feel that way > too. > > -greg > > Gregory Burd | Product Manager > Oracle Database Engineering - Embedded Products, Berkeley DB > greg.b...@oracle.com or follow me on Twitter or Identi.ca as @gregburd > http://blogs.oracle.com/berkeleydb/ > -- View this message in context: http://old.nabble.com/Oracle-joins-the-SQLite-Consortium-tp28947200p28971317.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
