Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Databases Programming Software IT

Sun Eyes PostgreSQL 339

Da Massive writes "Sun is looking seriously into the database market - namely PostgreSQL. It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter. This from John Loiacono, executive vice president of software: "We're not going to OEM Microsoft but we are looking at PostgreSQL right now," he said, adding that over time the database will become integrated into the operating system."
This discussion has been archived. No new comments can be posted.

Sun Eyes PostgreSQL

Comments Filter:
  • I doubt it (Score:3, Funny)

    by FortKnox ( 169099 ) * on Wednesday October 05, 2005 @11:30AM (#13722491) Homepage Journal
    It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter.

    An NFL punter usually makes between $250k to $1M a year. They can handle most DB costs...
    • Re:I doubt it (Score:4, Insightful)

      by Anonymous Coward on Wednesday October 05, 2005 @11:36AM (#13722550)
      An NFL punter usually makes between $250k to $1M a year. They can handle most DB costs..

      No, they can't. That is the problem...
    • Does anyone know the usage of the word "punter" in the article, though? I've heard the root word "punt" in several different ways in the last year or so when I had only heard it in the American Football context.
      • Re:I doubt it (Score:5, Informative)

        by iBod ( 534920 ) on Wednesday October 05, 2005 @11:51AM (#13722668)
        A 'punter' is common British slang for 'your average joe'.

        Also used to mean a gambler or a prostitues client!
      • Re:I doubt it (Score:3, Informative)

        by Dun Malg ( 230075 )
        Does anyone know the usage of the word "punter" in the article, though?

        It's a British-ism meaning about the same as "bloke", only it can apply to men or women. Tends to have shades of "lowest common denominator" to it, meaning something like "an ordinary slob off the street picked at random".

        • It's a British-ism meaning about the same as "bloke", only it can apply to men or women.

          I've mostly heard it used/used it myself to describe "customers", particularly gamblers. As in "I had a punt on that nag but lost my shirt". I believe politicians use it to describe their electorate, but I couldn't possibly comment.

          Disclaimer: I've only heard the term used in Scotland; it's usage elsewhere in Britain may be more/less general.

          • I've mostly heard it used/used it myself to describe "customers", particularly gamblers.

            Exactly. It means customer, not 'bloke' or 'average joe'. Since it's a slang word you'll only hear it being used colloquially, usually in terms of gambling, market stalls, bars, clubs, brothels, etc.

        • Re:I doubt it (Score:4, Informative)

          by gowen ( 141411 ) <gwowen@gmail.com> on Wednesday October 05, 2005 @12:00PM (#13722741) Homepage Journal
          It's a British-ism meaning about the same as "bloke"
          More usually, it means "someone who is in interested in buying something". It's most frequently used with respect to gamblers (particularly occasional horse-racing gamblers), since "having a punt" means "taking a gamble." It also means "people who frequent prostitutes", thus PunterNet [punternet.com], the leading online guide to "facilitate the exchange of information on prostitution in the UK"
        • punter == mark (Score:3, Informative)

          by HermanAB ( 661181 )
          American slang for 'punter' is 'mark'. A gambler, but more specifically, a loser.
      • Re:I doubt it (Score:2, Informative)

        by Doctor Memory ( 6336 )
        It's British for "Joe Six-Pack"
      • Re:I doubt it (Score:3, Informative)

        by nelsonal ( 549144 )
        In this context punter is a buyer with shades of uninformed buyer. The term comes from the race tracks where betters became known as punters, and has evolved to refer to more uninformed buyers of especially tech and financial products.
      • by Alejo ( 69447 )
        Dude , I have no idea.
      • Since you're unfamiliar with the term, you must be unfamiliar with The Register. [theregister.com] The BOFH alone is worth the price of admission.
    • Well they did say the average punter, not the average NFL punter. Even though NFL punters make a lot of money, all other punters (college, high school, little league) make nothing. There are hundreds of thousands of non-NFL punters vs. a couple hundred NFL punters at the most, so that would effectively bring the average very low, well below poverty levels.
    • Re:I doubt it (Score:2, Insightful)

      by dtfinch ( 661405 ) *
      The average football punter isn't in the NFL.
    • by iabervon ( 1971 ) on Wednesday October 05, 2005 @12:08PM (#13722809) Homepage Journal
      Punting costs £14-16 per hour, which is a lot less than a database. Of course, I've got no idea what you'd use a database for while poling a boat around the river Cam [scudamores.com].
  • Predictable (Score:5, Informative)

    by AKAImBatman ( 238306 ) * <`akaimbatman' `at' `gmail.com'> on Wednesday October 05, 2005 @11:31AM (#13722495) Homepage Journal
    This really isn't a surprise. MySQL has both licensing problems, and feature problems in the competitive high-end markets. PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server. These features led RedHat to PostgreSQL for their RedHat Database [redhat.com] product, and I see little reason why they wouldn't attract Sun as well.

    The only thing that slightly bothers me about their strategy is that Sun has been pushing their Java Systems hard. If they actually wanted to bolster that strategy, they'd have three major options for a Java Enterprise Database:

    1. Cloudscape/Derby [cloudscape.com] - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.

    2. Daffodil [daffodildb.com] - This database is an excellent choice, but it would require the acquisition of another company, a move that the Sun shareholders might question. It would also bring quite a bit of flak in Sun's direction as Daffodil is an Indian company.

    3. McKoi SQL [mckoi.com] - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.

    As for the choice of Sunbird, I think it's simply a matter of "why not?" It's not like there's any particular leader in the market, and Sunbird plays nice with Firebird/Mozilla.

    • Sun's Java Enterprise System is about programming in Java rather than the tools in Java. The technology of the product isn't hugely important its the fact that the API and development is in Java. Databases are clearly easy with Java as JDBC makes the actual choice a pure commodity. So what Sun want is a solid database, for free, that rounds out their platform effort and means that in one download and license a client can "get started"... which often means it is all they use.

      • Sun's Java Enterprise System is about programming in Java rather than the tools in Java. The technology of the product isn't hugely important its the fact that the API and development is in Java.

        Agreed. The only point I'm making is that having a Java infrastructure assists Sun in marketing the JES technology stack. If the entire thing is Java, and obtains a reputation for performance, reliability, and security, then it only makes Sun's Java strategy look better. With "native" components, critics are able to
    • Re:Predictable (Score:4, Informative)

      by MeauxToo ( 644228 ) on Wednesday October 05, 2005 @11:52AM (#13722684)

      1. Cloudscape/Derby - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.

      Derby is intended to be an embedded database, not a database server. Yes, they have a server mode, but can't hold a candle to MySQL, let alone, PostgreSQL.

      3. McKoi SQL - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.

      Since when can't you modify the source of a product with a BSD-based license? A BSD-based license is, in fact, far more liberal than the GPL because you can take the code, modify it, and close the source of the result. A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD, and last I checked, Windows is not open source. In contrast to the GPL, where you have distribute any modifications you make and open-source any parts of your products that link to it. Hence, the description of the license as viral.

      Speaking from experience, PostgreSQL is a grat product. Stable, reliable, and reasonably fast for medium to large scale, multi-user, distributed environments. The products listed above are all embedded databases intended for single user, micro environments. You are, in short, comparing apples to oranges.

      • Since when can't you modify the source of a product with a BSD-based license?

        If you could be so kind, could you clarify what you are referring to? I believe I said that "the GPL license allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL." I'm not certain where your vehemence is targetted.
      • Re:Predictable (Score:4, Insightful)

        by david duncan scott ( 206421 ) on Wednesday October 05, 2005 @12:40PM (#13723115)
        A perfect example is the Windows NT/XP TCP/IP stack -- stolen straight from BSD

        Smile when you say that, pardner!

        "Stolen?" No, used legitimately. In fact, as I recall, you used to be able to look at the WinNT ftp client and read the credits to UC Berkely, which aren't even required any more.

        "Stolen" just undermines your point that the BSD license allows -- hell, encourages -- this sort of use.

        Of course, I think you misread the post to which you were replying, because that poster agreed with you that the GPL includes restrictions absent from BSD.

        I'd also check again with regard to XP. I think the Redmond boys may have rewritten that stack by now.

    • Re:Predictable (Score:3, Interesting)

      by Doctor Memory ( 6336 )
      I might also suggest Firebird [sourceforge.net], the open-source version of Borland's InterBase product. It's licensed under a variant of the Mozilla Public License called the "InterBase Public License", but it doesn't seem too onerous. It's still a young product, but it looks like a good base, and I'm sure with a little spit and polish from Sun it could be a decent system.

      There's also PostgreSQL's estranged mother, CA Ingres [ca.com], the commercial version of Stonebreaker's original University Ingres. This is a well-vetted comme
      • Re:Predictable (Score:2, Interesting)

        by hey hey hey ( 659173 )
        There's also PostgreSQL's estranged mother

        More like estranged cousin. The commercial version split off from the University version long before PostgresSQL.

    • Re:Predictable (Score:5, Insightful)

      by hey! ( 33014 ) on Wednesday October 05, 2005 @12:15PM (#13722865) Homepage Journal
      PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server.

      Depends, you can't exactly put a product like a RDBMS on a single scale. But in general it makes some sense to compare Postgres to SQL Server, but very little sense to compare either of those products with Oracle; although the limited attention span of most "decision makers" means that in practice the marketing departments of MS and Oracle play that game.

      Oracle really really wants people to use Oracle for everything, and in truth you can use it for a lot of day to day database tasks, in the way you could use an eighteen wheeler to take your kids to soccer practice. Oracle's not very standards compatible. There's a million ways it traps you into their product. There's endless ways to shoot yourself in the foot, and getting things back requires a kind of black sorcery. In short, Oracle really sucks, unless it's the only tool that can do the job; in which case it's wonderful. Oracle's built so you can perform heart surgery on the patient while he's running a marathon, for the kind of applications where serious money is lost every time the database hiccups; the kind of applications where you have a team of DBAs who are paid six figures and it's a bargain.

      SQL Server, to my mind, is mediocre. It's the choice of the departments who believe thing are easier if everthing comes from one vendor, and it's good enough to keep them out of too much trouble much of the time. From a DBA's standpoint I'd guess it's very easy to administer up to the point it becomes useless; if you never get there, you're happy. From a app develper's standpoint, it's pretty dreadful, but these days the style is to put as much as you can in the app tier so that doesn't matter much as it used to.

      Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.

      • by WebCowboy ( 196209 ) on Wednesday October 05, 2005 @01:10PM (#13723383)
        ...is probably the most fair comparison.

        Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.

        I have had experience with both in production environments, and I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability. It is much better than MSSQL with concurrency and managing contention (MSSQL's locking strategy is quite brain dead). There is much more flexibility and power to create user functions and stored procs in PGSQL--you can do things like make user-defined AGGREGATE functions and data types in addition to having a choice of languages (none of that is possible with MSSQL). I find that all things being equal PostgreSQL is probably faster as well (largely an assumption becasue the PostgreSQL systems I've worked with are running on considerably less powerful hardware than the MSSQL systems I am doing). A lot of people comment about the ease of administration of MSSQL but I find that PGSQL really isn't that hard to manage even if you don't use GUI tools.

        Oracle is certainly one step above PGSQL in power--but of course that comes with a very hefty price tag. That price isn't just in licensing either--Oracle takes more time to administer and you also pay by losing flexibility, since enterprise systems based on Oracle better do things the "Oracle way" or you are inviting trouble (just like with Microsoft products, Oracle really pushes its single-vendor solutions).

        I have not played with Yukon/MSSQL 2005 yet, though I've heard a fair bit about it. From what I've heard it closes the gap a fair bit and comes much closer to PGSQL in terms of features and performance--it is supposed to handle locking/contention better and its has embraced .NET--meaning that you can write stored procs and functions in any .NET language. So, they are probably a pretty close match except in a couple of areas--PGSQL is free (libre and gratis), and PGSQL is not platform dependent. I think that the fact MSSQL only works on Windows is a major drawback when all its competitors offer products that run on Windows, Linux and various UNIX derivatives. Various "facts" notwithstanding I still think that Windows servers are a greater administrative burden and more difficult to secure than other alternatives--perhaps the next server version after 2003 will have addressed that.
        • Why do people always forget about ingres, firebird and other great open source databases when this topic comes along. Isn't there anybody who can step in tell us their experience with those?

          By the way over the years I have been convinced that MSSQL developers follow postgresql development pretty close. They slowly seem to be adding all features postgres has to sql server. I bet they are even using a bunch of the same code.
        • > I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability

          that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000. A perfect example was stored procedures - where you couldn't return a result list in postgresql, and the python stored procedure language required so many ticks and escapes it was impossible to use.

          Regarding oracle, it used to be so much worse than it is today. For small databases it
        • Oracle is certainly one step above PGSQL in power--but of course that comes with a very hefty price tag. That price isn't just in licensing either--Oracle takes more time to administer and you also pay by losing flexibility, since enterprise systems based on Oracle better do things the "Oracle way" or you are inviting trouble (just like with Microsoft products, Oracle really pushes its single-vendor solutions).

          This can't be emphasized this enough.

          We develop for/administer both, and it costs Oracle clie

    • I don't know *anything* about those other products, but it strikes me that Postgresql could without too much effort have Java as a stored procedure language.

      Indeed, someone has already started it http://plj.codehaus.org/ [codehaus.org]

    • Derby (Score:2, Informative)

      by ievans ( 133543 )
      Sun already has several engineers working on Derby through Apache. Sun bundles Derby with Glassfish (the newly open-sourced Java EE 5 app server), which also integrates Derby into the app server for the EJB timer service, and bundles it with the Java Enterprise System stack. Sun is actively promoting Derby as a development database. There was a story about it here on Slashdot not too long ago.

      Sun used to bundle Cloudscape before IBM bought Informix, and subsequently switched to Pointbase. For App Server 9/G
    • ...Ingres would have been a better choice - it has the kind of commercial backing that their customers seem to like, has been released as Open Source -and- is supposed to out-perform PostgreSQL on enterprise-level platforms.

      Alternatively, have a database-independent wrapper and sell any of the popular Open Source databases according to customer needs. That leaves the door wide open to transparent, painless upgrades (always a good money-spinner) AND winning more hearts amongst those developing a phobia of lo

  • by jbellis ( 142590 ) <jonathan@carnageblen d e r . com> on Wednesday October 05, 2005 @11:32AM (#13722507) Homepage
    I'm not sure what they have in mind here, but if that's the direction they're going it's clear why they wouldn't go with MySQL (technical shortcomings aside). PostgreSQL's BSD license makes it much more attractive for Sun, whose CDDL license is incompatible with the GPL, IIANM.
    • by AKAImBatman ( 238306 ) * <`akaimbatman' `at' `gmail.com'> on Wednesday October 05, 2005 @11:40AM (#13722579) Homepage Journal
      it's clear why they wouldn't go with MySQL (technical shortcomings aside).

      Actually, I'd say that the technical shortcomings have a LOT to do with it. PostgreSQL can be placed head to head with Oracle and still pretty darn appealing. MySQL really don't have that capacity (yet), and is hampered by its non-ANSI comaptible design and SQL variant. So I'm not certain that the decision was made entirely on licensing alone. After all, Sun does support the GNOME project as well, and that is solidly under the GPL.
    • If they add it into the install process, they could have an all in one solution with db, web, web, and other services in one install pass.

      Combined with in a blade or other server format, SUN should be able to unit that smokes the others on TCO basis, and can be advertised at a fixed dollar price, w/o additional license fees.

  • by tcopeland ( 32225 ) * <tom&thomasleecopeland,com> on Wednesday October 05, 2005 @11:38AM (#13722560) Homepage
    Sun gets to use repackage PostgreSQL however they like, more people will be using PostgreSQL and finding bugs and adding features and writing utilities, more books will be sold, more consulting opportunities - everyone wins.

    I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part. And the products [sourceforge.net] that are based on PMD? Just means more books sold [pmdapplied.com]. Good times!
    • Sun gets to use repackage PostgreSQL however they like, more people will be using PostgreSQL and finding bugs and adding features and writing utilities, more books will be sold, more consulting opportunities - everyone wins.

      Nope. While it is true that more people can use the code and fix bugs ... there is nothing saying that those bug fixes must be released to the general public.

      So if Sun fixes a bug, they don't have to release that fix to anyone.

      So the bug will still exist in the base.

      This is what leads

      • Most BSD-license loving programmers have the (somewhat egotistical) attitude of "I'm releasing this because I hope it gets used." They tend to want the fixes out there.

        This is in keeping with the fact that BSD folks toil away on code for which they can't expect to charge any money.
        • Most BSD-license loving programmers have the (somewhat egotistical) attitude of "I'm releasing this because I hope it gets used." They tend to want the fixes out there.

          What does that have to do with anything? The "BSD-license loving programmers" aren't the ones deciding whether to release the fixes or not; Sun is the one deciding that. Without the GPL to force it to release the fixes (if and only if it distributes the fixed program to begin with), it's quite likely that it won't do so, because its share

      • Replace "fragmentation" with "free market." If people don't like the version that doesn't release its fixes as source, they can start their own version, and if it's superior, it wins out. Or if it's not as good as the closed yet superior version, the closed one wins out. And of course, you can choose whichever floats your boat no matter what.

        That's the freedom RMS and company don't want you to have.

        Besides, it's not like fragmentation isn't a hugely rampant problem in the GPL-based world. Unusually, the
      • by TheRaven64 ( 641858 ) on Wednesday October 05, 2005 @12:42PM (#13723146) Journal
        So if Sun fixes a bug, they don't have to release that fix to anyone.

        True, on the surface. However, if they don't then the next time someone modifies that bit of code, then they will have to re-merge their changes. If someone else fixes the bug in a different way, they have to do code review on both implementations and then decide what they want to keep.

        There is a reason people like Apple contribute to BSD projects - it's cheaper to get your patches merged upstream than to maintain a fork.

    • So? (Score:4, Insightful)

      by joib ( 70841 ) on Wednesday October 05, 2005 @12:16PM (#13722884)

      I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part.


      Just like there's plenty of people who only contribute to GPL projects since they don't want "evil corporations" stealing their code.

      You can find fanatics driven by ideology rather than common sense in both camps. That's hardly something to cheer about.
  • Sun Microsystems and PostgreSQL...good for Sun, good for the elephant database. I second the motion.

  • Question (Score:3, Insightful)

    by stoolpigeon ( 454276 ) * <bittercode@gmail> on Wednesday October 05, 2005 @11:39AM (#13722569) Homepage Journal
    If they take postgres and roll it into the OS- that means the work they do after that wont be coming back to the postgres community? I assume that is the likely course, or am I mistaken?
     
    I like the BSD license, and I understand what the ramifications of it are. And I'm not trying to start a debate over whether this is a 'good' thing or not. Just hoping someone here more knowledgable will give some insight on how this is likely to go.
    • Re:Question (Score:5, Insightful)

      by meringuoid ( 568297 ) on Wednesday October 05, 2005 @11:47AM (#13722639)
      If they take postgres and roll it into the OS- that means the work they do after that wont be coming back to the postgres community? I assume that is the likely course, or am I mistaken?

      Well, they don't have to give anything back, if postgres is BSD-license. But in practice, they probably will. Not everything, but quite a bit. It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications. Basically, if Sun want to take advantage of progress made by the community on postgres, then they'll be giving back some of their own. They don't want to diverge too far.

      • I guess what I wonder is-- if you make it a part of the OS aren't you basically forking it? Unless the ties to the os are not to the database engine itself.
         
        I think the postgres development community is strong enough that it doesn't matter. So I'm not worried about it, I just am curious about the implications of that one aspect.
      • Way back at the beginning of the *nix wars, there wasn't any incentive not to share the improvements and such of each version ... but they still fragmented.

        The same situation exists here. Sun is not legally bound to release any improvements back to the base, but can legally use any improvements that others provide to the base.

        It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary vers

      • Well, they don't have to give anything back, if postgres is BSD-license. But in practice, they probably will. Not everything, but quite a bit. It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications. Basically, if Sun want to take advantage of progress made by the community on postgre
    • Slightly OT- Is there a good resource online to compare the different open-source licenses available (GPL, BSD, etc.)? I'm googling a lot of FAQ's about each license in particular but I can't seem to find a comparison. I do know that the GPL ensures that derivative works will stay free, but other than that I feel pretty license-clueless.
  • "the database will become integrated into the operating system."

    I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.

    As much as I love PostgreSQL, I think it might be kinda heavy for that kind of implementation.
    • I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.

      Yeah. Like Windows' Registry?
      • Yeah. Like Windows' Registry?

        It's not a bad concept. I personally like the OS X method better, since it (at least in theory) better compartmentalizes individual applications, but when you get down to it what sucks about the Registry has more to do with the fact that it's on Windows than the concept itself.


    • I wonder if he means a database-oriented filesystem? There's no real reason to stop there... system and application configuration data in a database would be great.


      I don't know about whether DB oriented filesystems would be useful.
      However, as it is on most Linux systems, it seems like there are 27 different programs, all with their own poorly implemented db. It would be nice to have one DB to take care of everything, at least in theory.

      On my machine I have slocate, apt-rpm, rpm and gconf, just off the top
  • by Nuttles1 ( 578165 ) on Wednesday October 05, 2005 @11:57AM (#13722721)
    Unlike all the articles about linux and it's rise as an OS, Open Source databases do not have the same major difficulty. With an OS, every user that uses the computer has to know how to use the system. Conversely, with a database, most, if not all users will not care what database they are using. For example, for my job, I write and maintain a windows application that supports 3 different database back ends. Our clients can care less what database they are using. Only IT and whoever is in charge of the cash will probably care what database is running. In my experiance, IT will not really care what they use because DB issues don't usually take up the bulk of their time. As for whoever is shelling out the money, well that is a toss up, but the trend that I see is that more companies are opting for less expensive DB options.

    Again, open source DBs have a chance because not every user works with them directly. Also, the interface, SQL, is a much more standardized interface than with an OS. As a programmmer, writing queries to DB A is pretty darnd exactly like writing queries for DB B. So, I think that their will be much better competition in the database world as in the OS world.
  • by dtfinch ( 661405 ) * on Wednesday October 05, 2005 @11:57AM (#13722722) Journal
    I wonder if it would create any confusion if Sun started marketing Mozilla's Sunbird. It'd be nice to seem some fresh development on that project though.
  • Firebird anyone? (Score:2, Interesting)

    by MatD ( 895409 )
    Anyone know why they wouldn't use http://firebird.sourceforge.net/> ? I've used interbase in the past and I thought it was pretty damn good.
  • I wonder how the databases compare these days. Someone I know is working with an MS SQL Server database that's too slow to be usable, and I'm wondering whether I should suggest they go with PostgreSQL instead. How does PostgreSQL cope on Windows these days? Do you still need to VACUUM your databases? Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)? How does Oracle's performance compare to the rest?
    • by kpharmer ( 452893 ) on Wednesday October 05, 2005 @12:56PM (#13723271)
      > Someone I know is working with an MS SQL Server database that's too slow to be usable

      Not true, sql server is a fine database. Its problems have more to do with being excessively gui-driven, expensive compared to OS dbms, and owned by microsoft than anything about the speed.

      > and I'm wondering whether I should suggest they go with PostgreSQL instead

      not having benchmarked them, i would guess that sql server would be faster on the same hardware.

      > Do you still need to VACUUM your databases?

      I think an automated vaccuum has been created. But it was never a real issue in my opinion anyway - basically the existance of vacuum enables postgresql to speed deletions and updates - since some table maintenance can be performed asynchronously. So, cron (or task schedule) the thing to run nightly and you're fine.

      > Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)?

      Not yet, but it's getting there. 5.0 should be a big improvement, but it still has a long way to go - not necessarily implementing the essential feature set, but now making those implementations robust.

      > How does Oracle's performance compare to the rest?

      Depends on what you need to do: have a small database, or a medium-sized database that's purely transactional? The open source databases can do the job. But if you've got a large database, or want to do some analytics (like show simple trends of data) then oracle/db2/informix are your friend. These commercial databases can easily be 40x the speed of postgresql or mysql on the same hardware for analytical queries.
  • by cpu_fusion ( 705735 ) on Wednesday October 05, 2005 @12:13PM (#13722851)
    Using Postgresql as a database makes a lot of sense for Sun. Its BSD license makes it easier to use licensing terms that fit Sun's needs, it's desiged for transaction-heavy applications, and it has a solid codebase with a growing community.
          True, it is not written in Java, but neither is Solaris. Sun uses Java pragmatically, as everyone should, and since there are JDBC drivers for Postgresql, it really doesn't need the database written in Java.
          I think it's a smart move, and this news combined with the Google collaboration is giving me hope that Sun's management has suddenly woke up and smelled the coff... er I mean java.
  • by teneighty ( 671401 ) on Wednesday October 05, 2005 @12:35PM (#13723075)

    Sun gained an excellent database when they acquired Clustra. What happened to it and why are they now talking about Postgres? Are they really that intent on pissing away that investment?

  • From TFA "over time the database will become integrated into the operating system."

    When MS integrates Access into Windows, they will have NO customers left... IMHO
  • Hmmm. (Score:5, Insightful)

    by hey! ( 33014 ) on Wednesday October 05, 2005 @12:55PM (#13723259) Homepage Journal
    The article seems a bit heavy on posturing and light on details, almost like it's there to get the message across: fear Microsoft because it competes with its customers.

    Otherwise, it seems a bit curious to me, because it juxtaposes two things that don't seem to go together in my mind: High end database management and penny pinching. Prices for Oracle on low end hardware (x86 servers) are not high at all, certainly not high enough warrant any concern at all in any project that doesn't get staff and DBA time free. Once you pay for a couple of professional staff the Oracle license fees are not worth worrying about, if they are even a bit more productive. Prices for Oracle on big iron are shocking to people whose idea of a big software procurement is a couple of dozen boxes of MS Office, but in those environments they are likewise not out of place.

    Oracle's licensing model is incredibly byzantine. It takes days of study to get your brain around it. Once you do, what's obvious is that it is a reflection of the company itself: it's a complex machine designed to squeeze every last marginal dollar out of the customer. But -- the reason it works is that the prics are very carefully calibrated so you don't really save any money by going to the competitor. For example, if you just grab the biggest license you can on the x86 platform to make your life simpler, you will pay dearly. But if you are selective and understand the model resaonably well, Oracle is about the same or perhaps even cheaper than SQL Server on equivalent machines. Of course if you don't know what you're doing you'll be accidentally sending Oracle beaucoup bucks, like CA did a few years ago. I assume midrange and high end licensing for Oracle are the same: they maximize Oracle's revenue for the specific capabilities you license from them, and it behooves you to choose wisely.

    Of course, no pricing model works for everyone. Perhaps there are people on high end hardware who just need something that is very fast and very reliable, not highly configurably fast and as reliable as human ingenuity can make it. Which leads me to a conclusion:

    Talking about Postgres in the context of Oracle and DB2 is probably just posturing. It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications. So I'm guessing this is really aimed at delaying the encroachment x86/Windows/SQL Server on the midrange, by giving a big vendor seal of approval to Postgres, which is plenty good for the kinds of apps you run on SQL Server, and quite a bit better if the hardware is better.
    • Re:Hmmm. (Score:5, Informative)

      by oGMo ( 379 ) on Wednesday October 05, 2005 @02:16PM (#13723873)
      It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications.

      Actually that's not remotely true. We're not talking about MySQL here. PostgreSQL is quickly gaining all the "high-end" features of Oracle: tablespaces, failover, replication, etc. In some cases, they aren't yet as fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly coming into its own.

      On top of this, it's a lot less painful to work with, and the SQL featureset is far nicer. After having worked with them both on a daily basis, the only reason I'd willingly use Oracle is if I was working with terabytes of data and had lots and lots of money to throw at Oracle to make it work and support it. Which I don't. Like Sun is saying, this is unjustified for most people.

      • Re:Hmmm. (Score:3, Interesting)

        by hey! ( 33014 )
        Actually that's not remotely true.

        Remotely true? It depends. High end is a logarithmic scale isn't it? And it's a moving target. I'd say the very idea of "High End" is only vaguely useful. If you need the fine grained control of the physical database Oracle gives you, then PG isn't high end enough. And it doesn't matter if a particular feature exists if it doesn't exist in the form you need it to. On the other hand, if PG does what you need, then you're better off without the cruft.

        On top of this, it'
      • Re:Hmmm. (Score:5, Informative)

        by kpharmer ( 452893 ) on Wednesday October 05, 2005 @04:01PM (#13724585)
        > Actually that's not remotely true. We're not talking about MySQL here.
        > PostgreSQL is quickly gaining all the "high-end" features of Oracle:
        > tablespaces, failover, replication, etc. In some cases, they aren't yet as
        > fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly
        > coming into its own.

        Hmmm, as much as I like postgresql I don't see it that way:

        1. replication? it's most often used as a clunky way of implementing failover - yuck. In my large data architectures, replication is almost never used: it's almost always the worst solution to some problem.

        2. tablespaces? yep, they're good things to have. that's fine - i think oracle and db2 have supported them for around twenty years, so it's hardly high-end technology tho.

        3. failover? ok, this is critical - but there are also many different forms & flavors. I'm not familiar with what postgresql has so I won't comment - other than to say it needs to be rock-solid.

        ok, how about a few more:

        4. memory management: a high-end database should give you a ton of control over how memory is handled - especially when you plan to buy tons of it. Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces. These bufferpools (caches) are how to easily ensure that hits against some tables or indexes occur 99% of the time from memory, and others 50% because they're so much larger. I'm pretty sure that neither postgresql or mysql can do this.

        5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.

        6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.

        7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to. So, while db2 or oracle are scanning 10% of the data - postgresql or mysql still have to scan 100% of the data. That would result in a 10x increase in speed over postgresql or mysql.

        that's just off the top of my head - given a little time this list would double.

        Postgresql is a fine tool, and it has all the technology that db2 or oracle had 12-15 years ago. And that's a cool achievement, and qualifies it do a ton of cool projects. Plus, with time it will catch up. But it still has a *long* way to go.
        • Re:Hmmm. (Score:5, Informative)

          by nconway ( 86640 ) on Wednesday October 05, 2005 @08:24PM (#13726363)
          Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces.


          Yeah, Postgres doesn't currently support this. IMHO it isn't that useful -- the performance improvement I'd expect would be pretty small (for one thing, all Postgres buffering is done in addition to the kernel's buffering, so the net impact will be smaller). It also adds a significant administrative burden -- you need to configure which objects go in which pools, as well as how large each pool is.

          5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.


          DB2 may well be better than Postgres here, but your explanation above doesn't make a lot of sense. In Postgres, a committing transaction only needs to wait for the WAL record describing the transaction to be flushed to disk (multiple transactions that commit concurrently can be flushed via a single fsync(2)). That is the only I/O that needs to be done synchronously -- the rest can be done async (notably, this includes the table I/O itself -- the modified buffers are just marked dirty in memory and are subsequently flushed to disk). Note that a backend may also need to wait for dirty pages to be flushed from the buffer pool if it is trying to replace a dirty page with a clean one, but (a) those flushes are done via write(2), so there is not necessarily a disk flush involved (b) the background writer in 8.0+ is intended to resolve this by ensuring that most of the work of flushing dirty pages is not done by a normal backend.

          6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.
          ... assuming your table scan is CPU-bound, which is almost certainly not the case. In practice, intra-query parallelism is useful for two scenarios that I can think of: creating large indexes, and OLAP workloads in which you are running a small number of concurrent queries, each of which is extremely expensive. In more normal OLTP circumstances, the number of concurrent clients far exceeds the number of CPUs in the box, so you don't need to parallelize within each query. Still, I agree this would be useful to have in some circumstances, although it's a bit difficult to see how to implement it reasonably.

          7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to.


          PostgreSQL 8.1 (currently in beta) includes "constraint exclusion", which is essentially a primitive form of table partitioning (using inheritence and check constraints, you divide the data into tables with distinct check constraints; the optimizer has been improved to recognize when a child table can be omitted from the query plan by looking at the check constraints involved).
    • Re:Hmmm. (Score:3, Insightful)

      by drew ( 2081 )
      Talking about Postgres in the context of Oracle and DB2 is probably just posturing. It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications.

      For true high end applications this may be true, but for what >90% of Oracle customers actually need, they could switch to PostgreSQL without sacrificing speed, features, or flexibilty, and they could do it while saving not only on Oracle licensing fees but also on the six figure salary Oracle
  • by Thai-Pan ( 414112 ) on Wednesday October 05, 2005 @01:42PM (#13723638) Journal
    As a developer who works on databases a lot, I still find it very arcane when I do have to get right down and dirty and work on files again. It seems very primitive in a world of SELECTs and INNER JOINs.

    I personally think every OS should ship with some sort of a light db engine equipped to handle databases stored in files. Imagine if you could write a simple application that opened databases just like you would with a db server, only using a file instead. When it comes time to scale it to a larger application, switch one line and connect it to a server instead. Or have your application configurable so that the user can either store it in a file or on a remote server simply by changing the server info from "c:\database.db" to "server:1234".
    • Thank goodness for SQLite, then. Just add the dll (or dependancy for linux-folks) to your package and voila. This also assumes you're using some DB-abstraction layer, such as PDO, ADO, ADO.Net, etc...

Neutrinos have bad breadth.

Working...