On 11-10-2010 04:38, mdipierro wrote: > This all happened in less than 2 months: > > http://blogs.computerworld.com/16741/oracle_dumps_opensolaris > http://www.techeye.net/business/creator-of-zfs-to-leave-oracle > http://openquery.com/blog/ken-jacobs-leaves-oracle > http://www.theregister.co.uk/2010/10/07/mysql_veteran_leaves_sunoracle/ > http://www.theregister.co.uk/2010/09/28/openoffice_independence_from_oracle/ > http://arstechnica.com/tech-policy/news/2010/08/oracle-sues-google-over-use-of-java-in-android-sdk.ars > > http://globalspecials.sun.com/store/mysql/ContentTheme/pbPage.categoryEnterprise?resid=MKgYhgoBAlcAAE77WocAAAAD&rests=1286764426624 > > The last link affects us more directly. If you have to choose use > postgresql, not mysql. > > Massimo and how will that affect SQLite ? this was on the SQLite group 21 july 2010:
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
