Slashdot Mirror


Oracle Acquires Sleepycat

Deven writes "Computerworld is reporting that Oracle has just acquired Sleepycat Software (makers of the open-source Berkeley DB embedded database) for an undisclosed sum. Having previously acquired Innobase, Oracle is certainly taking a look at diversity."

57 of 403 comments (clear)

  1. May I be the first to say... by spectre_240sx · · Score: 4, Funny

    God Damnit

  2. Interesting .... by joe_n_bloe · · Score: 5, Interesting

    .. o O o ..

    Can Oracle's acquisitions be predicted based upon the database backends used with MySQL? What other backends work with MySQL?

    1. Re:Interesting .... by jadavis · · Score: 5, Informative

      How many of those engines are distributed under a free license and have transactional support? Looks like both are owned by Oracle now. Oracle did that for a reason, and it's not because they like to collect database companies.

      Many users of MySQL depend on one or more of:
      (1) the ability to license MySQL commercially with one of those engines cheaply
      (2) the continued development of those storage engines
      (3) the continued development of MySQL

      Oracle can now stronly influence all of those things. #1 they can just raise the price or not license. #2 they can just lay off all the developers. Good luck getting an open sources devel team together before it's too late. #3, they can just refuse to license those backends, thereby preventing #1, which is also MySQL's source of revenue, leading indirectly to exactly the same case as #2.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    2. Re:Interesting .... by dgatwood · · Score: 2, Insightful
      Name one computer company that doesn't have any off-site contractors. As soon as you're talking about corporate internal apps, requiring them to be public open source apps in order to be allowed to use them within your company (off-site contractors included) or within companies that you work with closely (e.g. part suppliers for a manufacturing firm), the use of GPLed software becomes a show-stopper. (Bear in mind that none of such software would ever be useful outside the organization in question, but could reveal internal processes in a way that could cause harm to the organization.)

      Also, remember that what you're talking about is only the FSF's legal opinion on the subject. While this can be construed as being effectively part of the license for software copyrighted by the FSF, it is not binding upon any other GPL software author, which means that for any corporate environment to embrace GPL software directly is a scary thing, requiring legal departments to contact the authors of each individual GPL program and ask them to confirm that their interpretation of the license coincides with the interpretation presented by the FSF.. About the only way I would ever touch MySQL in a corporate environment without a commercial license would be through a layer of indirection like PHP or Perl (whose licenses are dramatically more palatable for corporate use).

      The bottom line is, if it isn't in black and white in the license, a legal opinion from the FSF isn't worth the paper it is written on... and even if it were, their opinion is still too restrictive to be practical for most in-house corporate use in a company with over about a hundred employees, where contractors do work at home or off-site at vendors, where vendor relationships do require sharing of internal tools, and where any limitation on internal or partner distribution will require either buying a commercial license with non-GPL terms or simply being unable to use the GPL software at all.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    3. Re:Interesting .... by Jamesday · · Score: 2, Insightful

      MySQL's view is that within a company is not distribution and no license is needed for GPL software. For software linked with a GPL library to connect to the server its view is also that within a company no license is needed. For redistributing outside when linked with a GPL library, its view is that you can use GPL or lots of open source licenses and still pay nothing at all. And if you don't want to be open source, its view is that that's OK also but it's going to charge you money so you contribute to open source in that way instead. And that helps to pay the wages of the few hundred people working for the company who are helping to improve MySQL for your benefit and that of everyone else.

    4. Re:Interesting .... by HiThere · · Score: 4, Insightful

      Unh.... The problem exists because those programs *weren't* under the GPL.

      Now I suppose that it's true that you can equally fork the open code of a BSD project, but it won't necessarily all be open.

      OTOH, it's also true that if MySQL were involved with the SleepyCat code, it wouldn't take them long to issue a new edition...provided that the licenses allowed this, as I'm pretty sure they do. (I don't know. I'm not lawyer, and I've always though of SleepyCat as proprietary, with all the dangers that that implied. I've also thought of it as OpenSource, in distinction to, e.g., Faircom's CTree.)

      Maintaining the back-end to the database would be more work, but there doesn't appear to be anything inherently impossible about it. And until you do get it working, you can continue to use the present version.

      InnoDB may be much more problematical....but isn't MaxDB a totally separate product that is equivalent to MySQLDB, but with built-in B+Tree? (This *is* a serious question, as I've only been peripherally following this issue...but I thought that I had heard that it wasn't really anything serious.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    5. Re:Interesting .... by killjoe · · Score: 2, Informative

      In order for the GPL to kick in two things have to happen.

      1) You have to modify the code.
      2) You have to distribute the code.

      How many corporations have interest in modifying the code of berkleydb or innodb? Unless you make databases for a living I don't see why any corporation would even want to look at the code.

      --
      evil is as evil does
    6. Re:Interesting .... by Trepalium · · Score: 2, Informative

      Where did you get this $500/client figure? They certainly charge $600/server. There are plenty of things to criticise MySQL over without making stuff up.

      --
      I used up all my sick days, so I'm calling in dead.
    7. Re:Interesting .... by Alioth · · Score: 3, Insightful

      The _whole point_ of the GPL is to have conditions on the very things you say should be removed. The GPL doesn't need to be changed - if you don't like the conditions of the GPL, use BSD (or other) licensed software. MySQL chose the GPL for a reason - if they wanted a license with the features that you list they would have used a license like that; but they did not.

      If you don't want a GPL'd database, use PostgreSQL.

  3. Why do this? by BigZaphod · · Score: 2, Interesting

    Why buy up all these other database alternatives? The only good reason I can think of is that they are trying to cover all ranges of database needs. I guess that makes sense, but are they going to combine all of these products into one interoperable system and thus destroy the original advantages the previous products had?

    1. Re:Why do this? by larry+bagina · · Score: 2

      Berkeley DB was, is , and will always be open source. The Cat is out of the bag, and it's not going back in. I say hurray to Sleepy Cat: The open source world has a database and they got an undisclosed bonus for all their work.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    2. Re:Why do this? by jadavis · · Score: 4, Insightful

      There are two important decisions that I think are relevent:

      (1) Oracle bought not one, but TWO mysql backends, which happened to be both of their transactional backends.
      (2) MySQL AB licenses the client libraries under the GPL.

      The only conclusion that I can come to from either of those is control.

      MySQL AB needed control over their MySQL database, and so they restricted the distribution of the client libraries. You can argue about what licenses are acceptable for libraries in general, but for a client-server program, it is very strange to restrict the distribution of the client libraries. The decision therefore must have been deliberate, and made for a business reason. That reason is control.

      And Oracle obviously made a business decision. There was question about the motives after buying Innobase, but those questions are now answered when they purchased the only remaining candidate for a transactional storage engine for the MySQL commercial product.

      So here we have Oracle which clearly thinks they have control over MySQL AB, and MySQL AB which clearly thinks they have control over the MySQL database. For that to be false you would have to assume that one of those companies made a serious error in their business decision. So, Oracle now has some substantial degree of control over MySQL database.

      To prevent Oracle from exercising this control, we need to
      (1) fork the MySQL database
      (2) do a cleanroom reverse engineering of the client libraries and make them LGPL/whatever (in order to keep current commercial MySQL users in business)
      (3) fork InnoDB and/or BDB to make sure we have an open source backend that is actively developed.

      By that time, it will all be irrelevant.

      Fortunately, PostgreSQL is immune from these types of licensing problems. The client libraries and the database itself are freely destributable. And the developers work for a wide variety of companies. As far as I know, FirebirdSQL, Inges, and SAP DB are also free of licensing problems. That's 4 good alternatives if Oracle really tries to set MySQL back.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    3. Re:Why do this? by IdleTime · · Score: 4, Insightful

      Good Luck in writing a transactional backend engine. It's hard work and requires quite a few people with deep knowledge of databases on a very low level and I know since i work in the business. Add to the fact that you have to start from scratch, that you will have to come up with something that has enough performance to be a viable alternative and it needs to be tested thoroughly on all platforms and be wordsize and endian independent.

      Some people talk out of their behind.

      --
      If you mod me down, I *will* introduce you to my sister!
  4. diversity???? by slackaddict · · Score: 2, Insightful
    "Having previously acquired Innobase, Oracle is certainly taking a look at diversity."

    Uhhh... it looks to me like they are purchasing their competition to either insure it isn't developed to the point that it can be a serious threat to their own database product or to quietly change it so much that it's useless and kill the project. Wouldn't be the first time this has happened...

    --
    ConsultingFair.com
  5. Damn. by cosmotron · · Score: 4, Interesting

    What a bad reason to lay off their employees. I can't believe that they bought another company...

    --
    Ryan - http://www.thecosmotron.com/
  6. The "Symantec" and Macromedia Approach by joe_n_bloe · · Score: 2, Interesting

    Buy good product. Stop selling product.

    Drove me nuts back in my Mac programming days. But at least now developers can fork the open source code, should the creator decide it shouldn't be so open any more.

  7. SleepyCat huh? by rob_squared · · Score: 3, Funny

    Well, don't walk around their headquarters at night then, you might trip on the damn thing because its sleeping in the middle of the hallway.

    --
    I don't get it.
  8. Taking a look at Diversity? by hedronist · · Score: 5, Insightful

    Diversity? It looks more like careening towards homogeneity to me. First they bought Innobase, giving them the ability to cut MySQL's transaction nuts off, then they buy another open-sourece-friendly DBMS which has transaction capability.

    Now, if you were the largest commercial DBMS vendor in the world and you were worried about the OSS people moving into your space, what would you buy in order to stop them cold? Me? I'd keep them out of atomic transaction space.

    Do keep in mind we are talking about Larry Ellison here. Just google on "larry ellison greed" to see what some other people think of this champion of diversity.

    1. Re:Taking a look at Diversity? by saifatlast · · Score: 2, Funny

      Now, if you were the largest commercial DBMS vendor in the world and you were worried about the OSS people moving into your space, what would you buy in order to stop them cold?

      Shhh!! You idiot, don't give them any ideas!!

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't regist
    2. Re:Taking a look at Diversity? by dodobh · · Score: 3, Insightful

      Except that the closest competitor to Oracle is PostgreSQL, and _that_ one is slightly harder to buy out.

      MySQL just had the hype.

      --
      I can throw myself at the ground, and miss.
    3. Re:Taking a look at Diversity? by Deven · · Score: 3, Informative

      Diversity? It looks more like careening towards homogeneity to me.

      I should point out that the Slashdot editor changed my words while leaving them attributed to me.

      I said nothing about diversity. My original quote was "Having previously acquired Innobase, what does the future hold for these open-source databases?" The editor changed the end of the sentence to "Oracle is certainly taking a look at diversity." -- those weren't my words, despite remaining inside the quotes.

      But hey, I got a submission accepted, and that's always nice! :-)

      --

      Deven

      "Simple things should be simple, and complex things should be possible." - Alan Kay

  9. Two MySQL backends owned by Oracle by jadavis · · Score: 5, Interesting

    Oracle now owns two MySQL backend products. First InnoDB, which was their primary transaction-supporting backend, and now BerkeleyDB. Now, in order for MySQL AB to license MySQL database commercially, they need Oracle's permission (that is, if they want basic database features like atomic transactions).

    And if you don't get a commercial license from MySQL AB, you can't link the mysql client library to a non-GPL application. That means, if you have a non-GPL application and you want to add support for MySQL, you are now dependent on Oracle.

    --
    Social scientists are inspired by theories; scientists are humbled by facts.
    1. Re:Two MySQL backends owned by Oracle by QuantumG · · Score: 3, Interesting

      Call me crazy, but isn't it trivial to write your own client lib? I mean, looking at the source code here, it appears to just be a wrapper that opens a socket (tcp or unix), writes your plain text SQL request to it and reads back the response. I can remember someone asking me to add mySQL support to an app about 6 years ago and I didn't even use the client lib cause I didn't think anyone would need a library for something that simple.

      --
      How we know is more important than what we know.
    2. Re:Two MySQL backends owned by Oracle by jadavis · · Score: 2, Insightful

      That's a mighty fine line you're trying to draw. The way I understand it, the GPL kicks in anytime copyright law would, i.e., when you copy it and it's not covered by fair use. And copying windows 100 times in an office certainly isn't legally fair use.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    3. Re:Two MySQL backends owned by Oracle by dickko · · Score: 2, Informative
      The way I understand it, the GPL kicks in anytime copyright law would, i.e., when you copy it and it's not covered by fair use. And copying windows 100 times in an office certainly isn't legally fair use.

      You can't copy windows 100 times because of a little item in the EULA:

      1. GRANT OF LICENSE. Manufacturer grants you the following rights provided that you comply with all terms and conditions of this EULA: 1.1 Installation and use. You may install, use, access, display and run one copy of the SOFTWARE on the COMPUTER. The SOFTWARE may not be used by more than two (2) processors at any one time on the COMPUTER, unless a higher number is indicated on the COA.

      You'll not see anything like the above in the GPL. In fact under "TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION":

      3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
      The GPL is a "distribution" license (don't know if that is an official term, I've just seen it used here before), it doesn't care how you use the code, so long that any publicly available derivation includes access to the source code
  10. Chump change to Oracle by jonsmirl · · Score: 5, Insightful

    The price of these acquisitions is chump change for Oracle. My bet is that they are buying these companies to destroy them. Oracle does not want something like Mysql becoming a real threat to their DB business, so the tried and true solution is to kill the babies before they grow up. They will attempt to migrate what customers they can and then stop development on the acquired code bases. The acquired developers, if they stick around, will be put to work building migration tools.

  11. Re:Its not competition - Oh yes it is by Snowhare · · Score: 3, Informative

    BDB is used as a backend engine in MySQL. It is one of the two best backends - the other being InnoDB. Oddly enough, Oracle bought InnoDB about 3 months ago.

    Sense a pattern?

  12. Re:Its not competition by jadavis · · Score: 2, Interesting

    Yes it does, as a potential replacement for InnoDB as a backend for MySQL. When Oracle bought Innobase (makers of InnoDB), all the MySQL people suggested improving the BerkeleyDB backend to make it their primary transaction-supporting backend. Now, looks like that's owned by Oracle to. Maybe it's a coincidence? Or maybe the licensing of MySQL really is a weakness*, and Oracle saw a cheap way to exploit it.

    * MySQL licenses the client libraries as GPL, meaning that any application that has support for MySQL needs to either be GPL or get a commercial license.

    --
    Social scientists are inspired by theories; scientists are humbled by facts.
  13. Oracle cannot kill the GPLed MySQL by Andy+Tai · · Score: 4, Interesting

    Oracle may have screwed up the ability of MySQL to license the proprietary version of their database and may even killed MySQL's primary revenue stream, but they cannot remove MySQL, Berkeley DB or innobase from the market. Maybe MySQL will adapt, or someone will pick up the MySQL business, but the Free databases will continue to gain on Oracle. Oracle's nightmare cannot go away.

    --
    Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
    1. Re:Oracle cannot kill the GPLed MySQL by nikoftime · · Score: 2, Interesting

      They can't kill off the GPLed MySQL, but they can kill off the **commercial version** by purchasing the backend products and then reducing or eliminating their development. This means that a company or third party vendor that wanted to develop an app using MySQL would not be able to use the commercial version of MySQL in an effective way (since they would now be tied to Oracle, and Oracle's development whims of development for the MySQL backend products like InnoDB and BDB), and they also cannot use the GPLed MySQL unless they want to GPL their own application.

      Oracle thus makes it sensible for any vendor who doesn't want to be tied to an rapidly deprecating platform to use the Oracle database.

  14. How will this affect BDB-using projects? by TheBracket · · Score: 2, Interesting

    I wonder how this will affect other projects using the BDB back-end (for example, OpenLDAP and Subversion). I imagine Oracle can't pull the source for already open versions, and it might be possible for a free fork to emerge if it is needed - but it could put a cloud over those projects while they arrange alternative back-ends.

    --
    Lead developer, http://wisptools.net
    1. Re:How will this affect BDB-using projects? by jrockway · · Score: 2, Informative

      Subversion was moving away from BDB in favor of fsfs anyway. The fact of the matter, though, is that BDB has all the features OpenLDAP and Subversion need... so even if SleepyCat doesn't release any more updates it doesn't really mean much to the individual projects. They can fork BDB and life will move on.

      --
      My other car is first.
  15. Challenge for Open Source by cyberjessy · · Score: 5, Interesting

    This could become one of the biggest challenges for Open Source in the years to come. The biggies could but these companies (often run by a handful of good men) for a small sum; and then change the way they function. Of course the old source will still be available, but the guys who know the intricacies will no longer be working on it. Bug fixes might be late, new features may never come. Many of the old users will leave, some stay hoping for the best. All the roadmaps vanish. Until someone picks up the ashes and starts again. Rebirth.

    I am not sure how fair it will be to ask any company/people to not take a multi-MILLION dollar offer, so that they would remain FREE.

    You can mod this funny, 'cause after I finished writing it feels like a para from MadMax.

    --
    Life is just a conviction.
  16. Are they just trying to derail MySQL? by IGnatius+T+Foobar · · Score: 2, Insightful

    I get the impression that Oracle is just doing this to screw with MySQL. As many know, MySQL gives you a choice of back end data stores. You can go with MAX (now owned by Oracle), or you can go with Berkeley DB (now owned by Oracle).

    As the developer of an application that uses Berkeley DB for all of its data stores, I am more than a little concerned about this. Does Oracle see any actual value in Sleepycat, or are they just doing this to shut them down?

    --
    Tired of FB/Google censorship? Visit UNCENSORED!
  17. Cutting MySQL's other leg off? by LLuthor · · Score: 3, Insightful

    This seems like it fits with their other purchases if their strategy is to kill of the commercial incarnation of MySQL. First the InnoDB purchase threatened MySQL's commercial business being the primary transaction based backend, and now BDB too is threatened.

    Can MySQL license the code (and any patents covering it) to continue commercial MySQL sales/support?

    --
    LL
  18. Re:Its not competition - Oh yes it is by Snowhare · · Score: 5, Interesting

    Do a Google groupd search for MySQL. Do a second one for Oracle.

    Surprise! MySQL has 75% as many messages about it as Oracle does.

    They damn well are competition. They are eating Oracle's entry market. Not everyone needs a super-duper database. A good enough free database trumps a extremely overpriced 'perfect' one in most applications.

  19. Raw Power by the+eric+conspiracy · · Score: 2, Funny

    Embrace
    Extinguish
    ????
    Profit!!!

  20. Re:Its not competition by jadavis · · Score: 2, Insightful

    Because, many people depend on commercially-licensed MySQL because they have a non-GPL product that they want to include MySQL support for.

    Now, the commercial distribution of MySQL may be weaker than the GPL version, because Oracle can stop licensing the "good" backends to MySQL AB for them to license to you. And the GPL version is highly restrictive because you can't link the client libraries to non-GPL clients.

    And if MySQL AB stops developing MySQL because they can't sell people a database without transactions, the development organization of MySQL database is gone. It takes a long time and/or a lot of help to get that organization back, and by that time it may be irrelevent.

    --
    Social scientists are inspired by theories; scientists are humbled by facts.
  21. Re:Its not competition by LLuthor · · Score: 2, Interesting

    As I said to the other poster: The BDB code may be covered by patents which Oracle could choose to exercise, thereby preventing the BDB code from being used despite its liberal license.

    --
    LL
  22. PotgreSQL... by curious.corn · · Score: 4, Interesting

    ... dodge this. Really folks, except for the nifty LAMP acronym what is it that keeps MySQL afloat? There's no reason not to go with PostgreSQL, a neat, cool and scary DBMS. If only those phpBB look alike script packs didn't insist hardcoding MySQL dialects in their code this would be a non story, it's that simple. It's like insisting on using VB just because everyone else does... and PostgreSQL documentation is good, so there's no "I can't figure it out" excuse.

    --
    Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
    1. Re:PotgreSQL... by Anonymous Coward · · Score: 2, Insightful
      What's keeping MySQL afloat? Hmmm... Incredible speed?
      Guess it depends how you use your database. MySQL tanks under any kind of concurrent load. MySQL eats flaming death with complicated queries. Neither does MySQL support features such as procedural languages, custom aggregates, bit-mapped indexes or tablespaces. In other words, it's either a really slow filesystem with a few extra features spooged on, or a reasonably quick toy database that's about the same speed as postgres, as long as you don't go trying to do something that would require a real database.

      Easy setup and administration?
      Yeah, postgres is really hard to setup.
      apt-get install postgresql
      sudo su - postgres
      createuser noob
      ^D
      createdb its_just_not_that_tricky

      Or you could just download and install one of the gui tools if command lines scare you.

      Handy SQL extensions?
      Oh, you mean like how there aren't any procedural languages supported? You know, the ones that would obviate the need for hackish extensions that only half solve a given problem? Or perhaps you're talking about all the dumb foot cannons that MySQL AB thought was clever?

      Enterprise features for those who want them and not for those who don't?
      Like... replication? Oh wait, that's a postgres feature that MySQL hasn't even dreamed of supporting. MySQL only just recently figured out what a transaction is a couple of years ago. They still haven't figured out NULL. I'm not sure exactly what enterprise features you're refering to, but then I don't think you are either since MySQL hasn't got any. Which is probably why nobody uses MySQL in enterprise environments whereas Postgres a non-trivial chunk of the internet.

    2. Re:PotgreSQL... by dmadole · · Score: 2, Insightful

      What's keeping MySQL afloat? Hmmm... Incredible speed? Easy setup and administration? Handy SQL extensions? Enterprise features for those who want them and not for those who don't? These things matter, and PostgreSQL, for all that it is an impressive database, does not have them.

      Not to mention built-in replication that you can setup in five minutes and just works. Last I looked, which wasn't too long ago, getting PostgreSQL replication working is a real mess involving other products.

      I used to use PostgreSQL extensively but the replication situation just killed me.

    3. Re:PotgreSQL... by slavemowgli · · Score: 2, Insightful

      Huh? Did you actually try PostgreSQL? I'll give you "SQL extensions", although I wouldn't call them handy myself (standards are there for a reason; proprietary extensions that lock you in to a single vendor should be avoided), but "easy setup and administration" and "incredible speed" are definitely things I'd say PostgreSQL has more of than MySQL.

      And yes, I've worked with both (not to mention Oracle, too).

      --
      quidquid latine dictum sit altum videtur.
    4. Re:PotgreSQL... by GooberToo · · Score: 2, Insightful
      You've stepped in it now! It's only a matter of time before a MySQL zealot, preaching Wikipedia as a reference, which is something like 98% read only, containing a few ....what million?...records, is a serious database. Which proves how MySQL is the king of RDBMS. Never mind that this is MySQL's sole strength...it's sweet spot... In the meantime, we'll ignore the fact that anyone that's done much with large and complex databases are laughing...but that's a different matter.

      You've been warned! Prepare to duck!

      Frankly, MySQL users are justifiably tired of being reminded that they picked an overhyped dog of an RDBMS and they will do just abou anything to assure their egos remain unbruised. It's not like you can really blame them. MySQL, as a company, has spread so much complete BS about PostgreSQL and even more BS about how great MySQL is, it's hard to debate the topic. You can always tell when someone is spewing the MySQL party line because it's always the same misinformation and complete BS.

      Here is a list of the common party BS lines:

      o PostgreSQL does not have replication. This is of course false. In fact, you have your ready choice of replication options; including commerically supported implementations.


      o Replication for PostgreSQL is complicated, inflexible, and painful to set up. This is, of course false. Replication can be set up in about 10-20 minutes, depending on your skillset and capabilities.


      o PostgreSQL is slow. This is of course false. Having said that, PostgreSQL may not be the fastest tool for every solution but it scales wonderfully. PostgreSQL's query optimizer, compared to MySQL's, is lasers versus clubs.


      o PostgreSQL is not stable. This is of course, false. This may of been true a decade ago. Realistically, even crappy biased (in MySQL's favor) tests which have attempted to compare the two are often unable to complete their tests with MySQL because it crashes or simply becomes completely unresponsive. MySQL is both unstable and scales poorly compared to just about any other well established RDBMS.


      o PostgreSQL is lacking key SQL features like MySQL. This is, of course, completely false! It is MySQL which is lacking many ANSI SQL features. In fact, like most of proprietary SQL vendors, they make every attempt to push their own lock-in extentions rather than support standard ANSI SQL.


      o Oh, let's not forget the classic... I've seen a website which is mostly read only run via MySQL, therefore, it's the best RDBMS ever created!



      This could go on and on and on...but you get the point.

      Summary:
      MySQL is used by the ignorant masses swayed by marketing hype and lies propagated by MySQL.
    5. Re:PotgreSQL... by curious.corn · · Score: 2, Insightful

      - Because MySQL fanboys consistently tout their favourite DBMS praising it for it's supposedly enterprise goodness.
      - Because MySQL web hosting is everywhere despite it's bugs, it's lack of features, it's violation of elementary SQL statement standards thus frustrating and bogging me down fiddling with the schema while I could do better things. Think MSIE HTML bastardization.
      - Because often I had to put up with it because some CMS, portal platform I wished to deploy has this damned DBMS hardcoded rather that wrapped in a sane Object to ODBC/SQLdialect mapping
      - Because all these pains in the ass happen because the common understanding is that since MySQL is the M in LAMP everyone should and will use it, just like sites designed and optimized around MSIE gaping bugs. ... and by the way, I'm a Mac user

      --
      Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
    6. Re:PotgreSQL... by Nohea · · Score: 2, Informative

      I think most PostgreSQL users checked out MySQL in the late 90's, and read the MySQL docs, to see if referential integrity was supported (i know i did).

      Not only did they say it was not supported, but that it would be stupid to implement it in the database, and that application developers should write their own code to do constraints.

      Well, the message was pretty clear to me - never give MySQL another consideration. Unless you want to do repetitive coding the rest of your life.

      http://developers.slashdot.org/comments.pl?sid=104 831&cid=8925689
      http://sunsite.univie.ac.at/textbooks/mysql/manual .html#Broken_Foreign_KEY

    7. Re:PotgreSQL... by curious.corn · · Score: 2, Insightful

      Maybe that explains it. maybe that rabid fanboyism and general jihad against everything not related to their favourite piece of software is spreading to PostgreSQL?

      Nope, first and foremost I'm a unix geek. Lived off Linux since RH5.1 and got the PostgreSQL syndrome way back. Mac user since OSX because of it's unix goodness

      When I started learning SQL I shopped around for a DBMS, tried MySQL, read the criticisms, hated the documentation, found the inconsistencies in the language, hated it for the inexplicable error handling, dumped it. Moved to PostgreSQL, walked through the tutorials, read about ACID, saw that I could do it on PostgreSQL and understand where I'd fail doing the right thing. Had some complaints on quoting in the SQL statements but overall found it comfortable to use opposed to messing around with obscure 'leet d00d gotchas sprinkled around.

      Many php script bunches, some quite neat, take MySQL for granted, like many sites do with MSIE. I don't want MySQL lying around my systems so I'm the one that's forced to follow other people's choices! What's so difficult in wrapping dB access behind a facade? Don't want to mess around with PostgreSQL? Fine, I can write and contribute the backend but if the mysqlconnect code is sprinkled around the scripts is it my fault for whining or is it because of poor design?

      MySQL bogs down when doing DB tasks, fast when doing pure reads; still slower that a filesystem though so why not just go with filesystem based spools? Those are easy to tar-up while MySQL chokes on it's own schema dumps and doesn't even warn about inconsistent data fields! It substitutes it with default values! It messes with the data and doesn't even tell me about it! Sorry MySQL is a toy, it's only good to discriminate those that know their shit from the wannabees.

      --
      Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
  23. Re:is that the way... by SwashbucklingCowboy · · Score: 2, Interesting

    Sure Oracle understands. They also understand that enterprises want support . Any company can pick up the source code to Berkeley DB and run with it. But that company cannot sell a commercial license, they can only provide support.

  24. [bdbxml-ann] Oracle acquires Sleepycat by Anonymous Coward · · Score: 2, Informative

    I'm pleased to announce today that Sleepycat Software has been acquired by
    Oracle.

    By joining the leading database company in the world, I expect that we
    will be able to serve our customers and the open source community better.
    With the additional expertise, resources and reach of Oracle, we'll be
    able to accelerate innovation, offer you greater choice, and provide more
    complete solutions. For Oracle, we fill a gap in the product portfolio
    for high performance embedded/edge databases, an area which we believe is
    a significant and growing opportunity.

    I assure you that we will continue to deliver the products and services
    that you are used to receiving from Sleepycat Software. We plan to
    continue developing, supporting and selling the entire family of Berkeley
    DB products, including our XML and Java Editions. There are no plans to
    change our dual license model, and we will continue to serve both open
    source and commercial users. Oracle will honor the terms and conditions
    of existing Sleepycat agreements.

    All of your contacts, phone numbers and email addresses for Sleepycat
    Sales and Customer Support remain the same. In fact, 100% of Sleepycat's
    employees are expected to transition to Oracle, so we retain all our deep
    technical expertise and community relationships. We look forward to
    working with you as part of Oracle!

    If you have any questions, please do not hesitate to contact us at
    info@sleepycat.com.

    Regards,
    Mike Olson
    Vice President, Oracle
    Former President and CEO
    Sleepycat Software

  25. PostgreSQL is safe from Oracle by Anonymous Coward · · Score: 2, Insightful

    I think Oracles recent acquisitions shows how semi-open commercial OSS can be a less reliable platform to develop on than truly OSS which isn't owned by any single entity.

    Sure the MySQL engines are open source and you can always fork it if they change the license, but forking such massive projects is unrealistic, and Oracle knows this.

    The project I'm currently planning is going to use PostgreSQL, instead of MySQL as usual; Oracle can't buy it because it's not owned by a single company. No matter how much Oracle tries to buy out competition there'll always be PostgreSQL.

  26. Comment removed by account_deleted · · Score: 3, Insightful

    Comment removed based on user account deletion

  27. Sleepycat responds by Chairman · · Score: 5, Informative

    I'm Mike Olson, Sleepycat's (now former!) CEO. I've taken a job as VP at Oracle working on embedded databases. Our entire team has come along.

    I've posted a summary of this announcement on the Sleepycat blog, at http://blog.sleepycat.com/2006/02/next-ten-years.h tml. I understand that a big vendor making a series of acquisitions in open source causes concern, but I'm convinced that the plan is as outlined in my posting. We're all showing up for work every day and working on the same embeddable database technology as ever. We're continuing to close deals with new customers and to support old ones. We continue to work closely with open source users.

    There's lots of speculation that this move is intended to damage MySQL. I frankly don't see it; MySQL doesn't depend on Berkeley DB. It never did. We've always had a close and cordial relationship with those guys, but both businesses have always concentrated on our own customers and markets. We may have wished, sometimes, that we collaborated more closely, but we never did.

    We've been good members of the open source community for a long, long time. We're pleased our software is so broadly used, and we're proud of the projects that rely on it. While I understand the concern, here, I'd ask that you watch what we do. I'm confident in the future of our products and of open source. Give us time to show you what Oracle and Sleepycat can do together.

    --
    Mike Olson, chairman@olsons.net
    1. Re:Sleepycat responds by hypersql · · Score: 5, Informative

      I don't agree MySQL does not depend on Berkeley DB. Without it, and without InnoDB, MySQL needs an alternative. In any case it's bad for MySQL, because some customers are probably already scared.

      I think what Oracle will do is change the work priorities inside Sleepycat. Development and support related to MySQL will be stopped completely. Developers will be re-assigned to do things like 'compatibility', 'migration' and so on. Future version of Sleepycat will just not work with MySQL any more. Probably the license agreement will change. Not sure if the code will be forked, but if the main developers of the codebase are gone (no longer working on it), the code becomes a legacy.

      Something very similar happened to me in 2001. I am the original author of Hypersonic SQL (a Java database engine). PointBase, who also developed a Java SQL database, asked me if I want to work for them, I said yes. We agreed I will continue to work on Hypersonic SQL. But this suddenly changed about half a year later, and they made me to work on something else (PointBase Micro, PointBase UniSync). So they 'bought' me (well, I only got shares, which are now worthless). And then tried to kill the competitor. They told me to stop the Hypersonic SQL project. But it was forked (HSQLDB). I left PointBase in 2003, and now I'm working on a new Java database: H2 (http://www.h2database.com/).

      MySQL will probably start developing their own transactional backend. They have now enough money to do that. They should do that, probably they already started (I was asked to work for them, but obviously I said no because of H2). My guess is MySQL will start a branch in the Bay Area, and hire some good developers there. There are quite a lot good database developers in this region.

      Thomas Mueller, former author of Hypersonic SQL

  28. Re:PostgreSQL... by kbob88 · · Score: 3, Insightful

    I completely agree: PostgreSQL should now be *the* open-source database of choice.

    I used to use MySQL extensively. Then six months ago, a new client required that we use Postgres. What an eye-opener! Honestly, I'm *never* going back to MySQL. I can't believe I wasted all that time trying to get MySQL work properly, configured right, rewriting SQL to work-around holes in their implementation...

    PostgreSQL is fast, stable, and full-featured. It also has a good *open-source* front-end GUI client, pgAdmin. Our production database has never failed in the four months since we released. The required configuration, administration, and maintenance is pretty minimal. You can fairly well just install it, create tables, and start putting data in. The feature set is so much better than MySQL. And you don't have to worry about some company (MySQL AB, or worse, Oracle) controlling your future.

    There are probably areas that MySQL does better (replication, perhaps?), but for most situations I have to think that Postgres is better. Plus, when your company gets bought out by the suits for big bucks and they switch you to Oracle, you'll have to rewrite less SQL than if you started with MySQL!

    Why is MySQL so popular? Marketing. I think MySQL just got some marketing buzz behind it (probably because they actually have a company to do public relations), then someone coined that dumb LAMP acronym, and O'Reilly publicized the heck out of it. Forget that LAMP stuff; go with LLPRR (OK, an even worse acronym) -- Linux/Lighttpd/PostgreSQL/Ruby/Rails. Or maybe Nitro/Og instead of Rails; hear it's great but haven't checked it out yet...

  29. Re:Berkeley - OID? by buchanmilne · · Score: 2, Informative

    Oracle can replace OpenLDAP, as OID

    I would say Oracle has an LDAP server, that's not very standards compliant, and that they may try and convince people can replace OpenLDAP. Whether OID really can is another matter. Performance-wise, apparently it can't.

    BTW, OpenLDAP isn't the only LDAP server that uses Berkeley DB on the backend, FDS/RHDS (the copy of Netscape Directory Server RedHat bought) and JES (Sun's copy of Netscape Directory server they got via the iPlanet alliance) do too.

    But what's it like to replace only the BerkeleyDB with Oracle, under an OpenLDAP server?

    Just like replacing any fast local database backend (bdb) with another abstraction (SQL) to a model (tables) that doesn't represent the frontend (hierarchical) that well, really bad for performance. OpenLDAP can already use any ODBC/SQL backend, though it's really not the first choice (the only real use is to expose data already in such a database via LDAP, not as a high performance LDAP server). Oracle, DB2, Postgresql, and MySQL have been used successfully (ie it works, but performance is always bad, no matter which is used).

    And what's it like to then drop the OpenLDAP part, leaving only OID?

    Slow and expensive?

  30. Re:Worrying by yomahz · · Score: 2, Informative

    First they bought out InnoBase, now SleepyCat, and it looks like probably JBoss soon..

    Is Oracle/Ellison attemping to simply buy out a good sized chunk of the mature open source offerings? For what purpose I wonder? To stop (or slow down) their competition with Oracle's own products? To use them against Microsoft and/or IBM?

    At any rate, I don't like it, not one bit


    I'm pretty worried about the JBoss move. I can't imagine Oracle has more than two motives here:

    1) Compete with IBM in the smaller, free application server market.

    2) Get rid of their open source competition.

    I have a hunch that #2 is much more likely. Jboss doesn't just have a competing applicaion server, it also has a competing ORM framekwork (Toplink vs Hibernate).

    --
    "A mind is a terrible thing to taste."
  31. Re:No, I'm quite right. by rthille · · Score: 2, Insightful

    A real company, shipping real and expensive software decided to spend lots of engineering time replacing Oracle with Sleepycat in order to lower the cost to store data in a database, with searching capabilities. Oracle made less money because of this. What would you call that if not competition?

    --
    Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/