Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Links

PostgreSQL - Oracle/DB2 Killer? 172

dagnabit writes "At Yahoo News, there's a story about a company which is investing in/supporting the PostgreSQL crew. Ultimate goals include "a planned expansion to 120 employees and the ultimate possibility of going public." So that enterprise-class open-source RDBMS may not be too far off after all... "
This discussion has been archived. No new comments can be posted.

PostgreSQL - Oracle/DB2 Killer?

Comments Filter:
  • The company I work at has used interbase with
    delphi 1-5 for six years now and it has worked
    very well. Now that Kylix is coming too, I am just
    waiting to port all of my projects to Linux. After
    that, no more windows at home. Umm...damn, could
    someone port NFS5 to Linux? Anyone? Please?
  • DOH! Sorry, try again, our Web host did something very bad they shouldn't have.

    Those responsible have been sacked :)

    Free T-shirt offer still applies for all Postgres users who complete the survey.

    thanks,
    Ned Lilly
    VP Hacker Relations
    Great Bridge
  • OK so it's only going to piss off us Brits but it's worth being a bit more careful when you choose the name of your global domination corporation. Any chance of "Pearl Harbor" making it to IPO?

    Wrong analogy: US freed itself from the British, while Pearl Harbor was attacked by Japanesee. The fact that US won (or UK lost) is not a bad thing, remember that they are good friends now. Or should any mentioning of US piss of Brits?
  • well, from over here it looks like Postgres is doing fine. Several flame squads have managed to kick the knees out from under the MySQL team (I've seen it on seven different BBS's in the past two weeks). This has piqued my interest, nonetheless.

    Let me give you a quick suggestion - change the name. Why? let's take a look at your competitors:

    1. Oracle. They have the best name, thus they have the best software. Everybody knows that if you ask an Oracle a question, it gives you the answer. VERY hard to compete with.

    2. DB2. Right away, we know what we're talking about here. And IBM has always been a leader in acronymized systems. I can't wait until DB3 comes out!

    3. Informix. Looking at the entymology of this sucker tells me it's going to be really easy to get my boss to use it.

    4. Sybase. Sounds cool. More importantly, I know how to pronounce it.

    5. MySQL. That's right, it's mine. For me. How much more fun can you get. I've got mySQL, you go get yourSQL!

    Now, lets take a look at your product: PostgreSQL. Wow. I can't wait to tell my boss about that, as soon as I figure out how to pronounce it. Is it named after some french mathemetician or something? I mean, I get the SQL part, but what is the Postgre? Am I only allowed to use it after I take my Graduate Requisite Exams? I mean, I pass that requirement, but if I hire someone who hasn't taken their GRE's yet will they be confused?

    Finally, I see in the threads here that there have been several competing versions about how to spell it: PostgreSQL, Postgres, PostGres, PostgresSQL, and so on. This is a major bug in the postgres source and must be fixed.
  • Some may be interested in comparisons of the major Open Source databases. This article at LinuxPlanet has some good information.

    The problem is the article is extremely scrappy, and ill-informed even in what it does cover. For exanple, it says: "POSTgreSQL is based on the commercial Ingres database system". This is completely untrue. Commercial Ingres was based on Berkeley's 'University' Ingres. Postgres was a completely different, later project by the same team at Berkeley which wrote University Ingres, but it doesn't share any code with it and it certainly doesn't share any code with the commercial Ingres product.

    It also repeats the old shaggy dog stories about how much faster MySQL is than Postgres, without quoting any benchmarks, or pointing out that this is only true for extremely simple queries.

    Finally, it doesn't mention the licenses...

  • Interbase is open sourced and is available today.
    Interbase is available, but it's not open source yet. The source code isn't out there, and more importantly it hasn't attracted a community of open source developers, bug reporters, etc.

    If you look at their web site, here's what they've got to say:

    InterBase Software is scheduled to release InterBase 6.0 for Linux, Windows and Solaris in open source format this summer.
    That's from this page: InterBase: the OPEN source database [interbase.com]. (Note the title: "the OPEN source database", and count the lies).

    BTW, I've been eavesdropping on the postgresql hackers mailing list, and their estimate is that Interbase is slightly better than postgresql, but they expect that postgresql will be as good or better in the near future, e.g. around release 7.1. I think that "outer joins" is the key feature that needs to be added.

  • In large scale software development projects, it has been my experience that typically, noone has full "mastery" of the code. You have individuals who have a full mastery of aspects of the code, and if you are lucky, the group as a whole will have mastery of the code base. Unlike you, the statement that they were working on mastery of the code actually gives me confidence in the code base. It tells me 2 things. 1) I am dealing with honest folk. A known problem is much easier to deal with than one which gets shoved under the rug by a team of marketing analysts worrying about how the admissions will affect their stock prices. Too often, vendors work hard to deny obvious defects in their applications. Honesty is refreshing. 2) Their gaining confidence as a team, and more ambitious releases will ensue. I just hope that their developing code "mastery" that is redundant across individuals as they will undoubtably suffer attrition as time goes on. - Pat
  • Yup.

    Oracle has replication, transaction logging, distributed locking, remote queries, scheduling etc etc etc.

    But yes, it is a pain to admin.
  • Do you drive an armored tank to work? Do you have a six gallon coffee maker? Some people need heavy duty equipment and some don't. In fact, sometimes the heavy-duty stuff is a hinderance to people who don't really need it.
    One size doesn't have to fit everyone.
  • I'm not sure about the JDBC driver specifically, but you have to be within a BEGIN WORK/COMMIT block in order to use large objects.

    Jon
  • Sorry you got -1'd for that. But your statement sums up exactly my point. Thanks for the support ;>

    ---
  • Once upon a time (mid 1980s?), a UC Berkeley prof developed a database called Ingres (which was later bought by Sybase?). Then we wanted to work on something relational database, so his next project was Postgres ("POST inGRES"). Then in 1995, some grad students had SQL support to Postgres, so they renamed it PostgreSQL. Yes, a terrible name. No one can agree on how to spell it, let alone pronounce it! :-\


  • That's why I said probably. I would personally opt for PostgreSQL. It's less expensive than both Access and Oracle, and will scale _well_ past Access.
  • by doom ( 14564 ) <doom@kzsu.stanford.edu> on Tuesday May 09, 2000 @10:51AM (#1083283) Homepage Journal



    "PostgreSQL" is hardly a catchy name. "MySQL" is. ;-)

    Yeah, I agree that this is a problem. A name like
    "PostgreSQL" is practically anti-marketing.


    I was considering doing a nominalogical fork,
    and release a new product based on postgresql
    which is completely identical except for the
    name.


    We can call it something nice and corporate like:

    • MyBase
    • PowerBase
    • OpenBase
    • FirstBase (Slogan, "Who's on --")
    • FreeBase
    • ACID Trip
    • ...
  • They could refund money to the distributors for any returned copies they haven't sold yet.

    That could be a lot of copies. Top management probably has some reservations about this whole weird "open source" thing. Throw in a couple hundred thousand on the wrong side of the ledger and you might wind up with obsolete binaries rather than released source.

    Or they could simply say that the "end of life" for the product is (some deadline) and promise to release the source once that deadline is past.

    Certainly. Of course, depending on the situation, that might well result in the eventual source release being even further delayed.

    If nothing else, couldn't the first open-source version be the minimum cleanup necessary from the last proprietary version, not a development version with lots of half-finished features?

    It depends on the situation. If the new version is a total rewrite and doesn't work yet, well, sure, the old version might be interesting. But most of the time, I'd want the latest code. Specifically in the case of Interbase, 6.0 is in late beta, feature-complete, and close to releasable; in fact, they might wind up putting out the source and the 'official' 6.0 release on the same day.

    -Graham

  • Actually, as I recall (someone check me on this) there was a v6 ODBC driver on the last beta that was sent out before the open source decision. The problem is, Interbase Corp. doesn't own the rights to it and therefore can't open-source it, at least not without permission. It does bring up a good point: What will the licensing terms be for the 6.0 ODBC driver? I think I'll go ask on their newsgroup...

    -Graham
  • Once upon a time (mid 1980s?), a UC Berkeley prof developed a database called Ingres (which was later bought by Sybase?). Then we wanted to work on something relational database, so his next project was Postgres ("POST inGRES"). Then in 1995, some grad students had SQL support to Postgres, so they renamed it PostgreSQL. Yes, a terrible name. No one can agree on how to spell it, let alone pronounce it! :-\


  • postgres-sequel, surely.

    (Cue pronounciation flame war. Perhaps we can get a definitive guide in the form of a .wav)

  • You're a friggin' genius. Now if we can just get the guys down in marketing to come up with a tripped-out advertising scheme...

    I wonder if the Volkswagon people are available?

    =P

  • But if you haven't ipo'd lately or aren't a multi-millionare company.. you can't go buying that type of equiptment.

    On the other hand, if you're a startup that can't afford to buy exotic iron, smarter software is a pretty good deal. Oracle performance tuning is a whole new weird and wonderful world; it's easy to screw up but you can do some great stuff too.

    So, with a little smarts, you can stay longer in the world of cheap commodity hardware.
  • Sure Oracle has a hell of a lot more features than Postgress. It had better since it's more than an Order of Magnitude larger (and yes, I know what that means). However for the majority of database tasks you don't need any of those extra features. In those cases people still go with Oracle for support and a developers infrastructure etc...

    It's like the case with Linux a few years ago when companies started to back it for profit. Sure it didn't have all the high-end features of other Unix or the ease of Windows but for many tasks it was more than good enough and for some it was the best choice. However, the boss wants to buy it somewhere even if he can get it for free.

    If these people can supply the support and the name branding, then developers can say, "just buy a database from this place". How about similar orgs for SamBa, and KDE. Well, I guess Burland / Corel is becoming that since this Kylix thing will generate pure KDE code on the QT libs.
  • by dhogaza ( 64507 ) on Tuesday May 09, 2000 @06:08AM (#1083291) Homepage
    The comment about gaining "mastery of the code" must be taken in context. The current team of developers are not the academic folks who originally developed it at Berkeley, and came together relatively recently (over the past three or so years).

    Obviously, being stone-cold to the code at the beginning it took awhile for them to learn and, as they put it, master it.

    So the statement made when 6.5 was released was meant as a milestone accomplishment, if you will.

    "We decided to take up and fix Postgres. In order to meet this goal we needed to collectively (not individually) master all the code. With 6.5, this milestone has been accomplished."

    The original authors and others from UC Berkeley who worked on it in earlier years have moved on to other things. The current team took the code, learned it on their own, and as of 6.5 had made vast improvements and fixed many bugs. 7.0 - released today - fixes even more bugs and makes referential integrity and various other features available.

    Regarding memory leaks that cause periodic crashing of the RDBMS, those were almost entirely fixed by 6.5, which was released a year ago.

    The /. article reference you mention was NOT entitled "Why MySQL sucks". It was simply a statement as to why the OpenACS team choose Postgres instead. We understand that MySQL fits a narrow niche quite well. We understand what that niche is, and more importantly isn't, much more so than do the developers of MySQL, judging from their documentation (foreign key constraints are almost always only used for documentation, so enforcement really isn't needed? Feh!)

    You might as well make an effort to quote the title correctly, even if you didn't understand what the piece was saying.

    That site, BTW, is running on Postgres V7.0 Beta (virtually the same version as today's PG release). It was slashdotted. My, oh my, enough to bring strong servers to their knees 'til they beg for mercy. Not this time - the dual P400 running AOLserver, Postgres and OpenACS never had to take off the sweats, much less work hard. It was running several other sites at the time, as well as being used for development that day by its owner, who wasn't even aware of the slashdot traffic until someone pointed out that his piece had (unexpectedly) been mentioned here. He then poked around and realized that the machine was serving lots 'o pages.

    Each page served out of that server involves several hits on a nearly 10,000 line datamodel stuffed into Postgres. There is ZERO caching of queries done on that server at the moment. Nada. Each page built dynamically out of the database.

    Those who don't think modern Postgres is fast enough for this kind of task ought to step back and think again. Those who think MySQL provides anything like the data safety of a true RDBMS ought to read a basic book like Gray's "Transaction Programming".

  • if you fill out the form for a free t-shirt on their web site, it asks you what features you want & they hit pretty well what PostgreSQL is missing - good blob support the biggest (and easiest to fix from the developer's standpoint) it'd be nice to see them dig in with some of the other features like replication & clustering.

    the big question i have (paranoia alert!) is that PostgreSQL is under a BSD license, so they don't need to release any changes they make if they don't want to. it didn't sound like that would be the case, but is this the first case of an OSS startup working with BSD-licensed code? it's a whole new ballgame compared to GPL.
  • by voidzero ( 85458 )
    Love the icon. Tux in a tux ;).
    Yes I know its a biz suit...

    Regret for the past is a waste of spirit.

  • Finally when we isolate one of those nasty "That's the way our product handles it" kind of performance bugs we can fix it!! Oracle has a VERY nasty one where for every row in a parent table all children tables are checked for data that would prevent the delete (in a FK parent/child relationship) regardless of wether or not those tables were empty. We had a delete on a 35,000 row table that took 25 minutes on a SUN E4500 w/ 6GB RAM and an optical disk array with a HUGE cache (something like 16GB) even though we deleted the children table right before deleting the parent table. Placing indexes on the FK's fixed the problem but still, it should only have to check those tables once and see 'It's not empty' then stop checking. Maybe we'll actually have an enterprise-level database that allows us to fix ugly crap like that ourselves instead of waiting for some stodgy company to decide your particular issue is high enough priority. I just don't understand why more companies don't go Open Source. Yes, I know it's a scary concept letting everyone see your source but legally no-one has any rights to that source that you don't give them. Your competition cannot legally steal your work (though wether or not they could get away with it quietly is yet to be seen). Really it does nothing but make your product a better product and attract people like myself who love having the code handy. -Zane
  • ...while looking for comparison reviews on OSS Linux EJB containers

    EJBoss (by Telkel) [telkel.com] is one of the OSS EJB container developments that I know of. Others are the efforts at the Apache Foundation [apache.org] and Enhydra [enhydra.org].

    Hope this helps...

  • The first partial cut of support for large types (not just blobs) is already available to developers. It's intended as a proof-of-concept for the particular approach being taken (the author wrote PL/pgSQL and did 90% of the work on foreign key support, among other things). But it is a good indicator that they're on track to have this out in V7.1, which will be available late this summer.
  • Couldnt agree more, the bloat is considerable. I suspect that it will cause Oracle serious problems soon. Some signs are there already - Sql7 now has the TPC C benchmark.

    In this context Postgresql is a pleasant change.

    Yet another 10 year Oracle dba ( 0.5 year Postgresql dba...)

    Markir
  • According to the IB-Architecture list (on egroups I believe) there is an ODBC driver under development that will be open source. A JDBC driver is also under development. The drivers are being written by Jim Starkey, one of the original developers of Interbase who is now back on the project.
  • I realize that this is an old thread and this may never be read. I worked in that group. I can assure you it is headed by an individual that has started many things and never finished them. Your assessment is valid. These cats are greed driven. Does that mean that its pig in a poke? maybe. maybe not. I can tell you this though its present chain of command is bogus. Maybe they will find the talent to do what they say. They do have some very successful projects. They also have some very deep pockets. Their gear would make landover jealous. I for one hope this one is a go. I will tell you this they seem to have a war chest and are aware that this is not a game of short term paybacks. Also this is a privately held group. I wouldn't bet on it going public.
  • you forget the phase when it was Postgres95, right about the time this 95/97/98/2000 business was starting.
  • it's hard to plugin core engine functionality. postgres has always had a set of plugin features, with a relatively limited scope - types, user-defined functions, etc. (that was actually the original point of the project). many commercial databases have comparable interfaces now. the predator [cornell.edu] project at cornell goes significantly farther in that direction. the real problem is that major plugins are a huge pain to write. an example: almost nobody outside of berkeley ever managed to write an access method plugin (think b-tree replacement) for postgres. it was just too hard to understand the lock manager, buffer manager, etc. etc.
  • I think it will take several years before it really can compete with oracle in the enterprise field. Good news anyway :-)

    Szo
  • Oracle/DB2 for the advanced features? Perhaps. I 've only heard of some really cool bells and whistles to Oracle and DB2, such as parallel serving and what not.. but think of it. How many people actually need these features more than just a standalone, i need someplace to put and analyze my data? Good fortune for Postgres.

    ---
  • an article is here [postgresql.org].

    the main thing that's not quite clear from the first paragraph is that postgres shared essentially no code with ingres. (a few hundred lines were ripped off for some utility code.)

  • When the "MySQL sucks" article appeared on /. last week, I began to look into Postgres because I began to think that perhaps I really did need some of the ACID features in my database. After 20 minutes of perusing the site, I gave up on the idea. Why?

    One of the "highlights" in the developer's page talked about how the new release version 6.5 represents Postgres' mastery over the source. What does that mean? According to the developers, it is the first release where they have someone on the team that understands every section of code.

    Let me tell you, that scared me away. I really don't like the idea of using a database where not even the developers have a firm understanding of the source; I don't want a nebulous developer response to a bug or a question. Combine that with the plethora of anecdotes about Postgres being great as long as you don't need speed or reliability (one guy reported having to restart the Postgres daemon every 5 minutes due to memory leaks!)

    Perhaps this new arrangement can bring some stability and speed to Postgres. I at least hope they will fix the bugs, as the idea of a free (as in speech) RDBMS is tempting.
  • well, let's start with basics. postgresql is process-per-user - the engine isn't multithreaded. this is a scalability issue for apps that produce a large number of connections. (it's less of an issue when you have someone managing the number of connections for you, like a web/app server.) that alone leaves oracle and db2 plenty of market-space that will never be challenged...

    the original article headline is inflammatory and, as you say, completely unrealistic.

  • Ok. I must accept that a matter of personal preference.

    But I also want to state that in my opinion this preference is wrong as it allows to make the code proprietary which I consider abusing it...

    If you have to decide about the license for =your= code, this is an entirely different matter (compared to bitching about the GPL of others code, which can regularly be seen on slashdor).
  • by Anonymous Coward on Tuesday May 09, 2000 @05:39AM (#1083308)
    How does it feel to be a killer? Yes, I realize that you haven't been convicted yet, but let's not candy coat things here. You're a murderer. I know it and you know it. Very soon the court will know it too. I don't care how much you pay whatever lawyers, justice WILL be served. Do you think about your actions before you commit these heinous acts? Are you AWARE of the consequences of your actions?

    I used to be really good friends with Oracle. He knew things, and told me when I would find cheese and when it would be brought to me. I loved Oracle as only a man could love a crappy metaphor. We spent almost all our lives together. He had a family, and our kids used to play together.

    Then tragedy struck. But you knew that. I didn't hear until a few days later. His wife came over and collapsed crying into my arms. Oracle and all seven of his children had been mercilessly slaughtered. And to make matters worse, you hadn't even left the scene of the crime. You were just sitting there, painting pictures on the wall with the blood, using Oracle's severed fingers as paint brushes. And your style was derrivative of Max Ernst. Don't get me wrong, Dada rocked and I live for surrealism, but try and be original, will you? Do you really think you're going to get anywhere floating on the works of others? oh. Well, yeah, I guess you might.

    Anyway, I shall not rest until you are behind bars, getting the beatings and rapings that you deserve. Hell, I've been taking volunteers for the position for the last three months. If any of the audience would also like to brutally beat and rape PostgreSQL in prison, please reply to this post and you will be contacted.

    you make me sick. there is no crime worse than databasecide . . .
  • At the bottom of the story was a mention that release 7 had been released today!
    So I check, and voila:

    ftp://ftp.postgresql.org/pub/v7.0/ [postgresql.org]

  • From my understanding of the situation here at Oracle, they can fund enough people to have one person maintaining each 2-10 thousand lines of code. So if you stay here for about 6 months you get reasonably familiar with the code you're responsible for. The code is done in C in a very object oriented fashion, and a lot of effort is put into making the interfaces and fully documenting the APIs. Additionally, the modules are rewritten if they are out of date or too obfuscated by poor original design.

    So... when you suggest that Oracle (generally) doesn't know what's going on in the code, you're off the mark. We do a fairly decent job with an absolutely huge code base. Remember that Oracle is several generations ahead of most of its competitors in terms of functionality, and you can't get to where Oracle is without a well honed infrastructure. No dozen people can be found who understand the whole database (not talking about applications here), but things work out fine.
  • Ok. Here is the Oracle code for table creation...

    http://www.cableone.net/cavanaugh/sql/ORATABS.SQ L

    Here is the MS SQL Server code for table creation

    http://www.cableone.net/cavanaugh/sql/SQLTABS.SQ L

    And this is it for MS Access

    http://www.cableone.net/cavanaugh/sql/MPDTABS.SQ L
  • by lubricated ( 49106 ) <michalp@@@gmail...com> on Tuesday May 09, 2000 @05:41AM (#1083312)
    you've never worked on a real software project have you. Linus said that he does not understand all the source making up the linux kernel. Yet many of still use linux. On big projects it is rare for one person to be able to understand all the code. And if the code is written properly than it really doesn't matter.
  • by Eric Green ( 627 ) on Tuesday May 09, 2000 @12:07PM (#1083313) Homepage
    I've been using PostGreSQL off and on since 1995, when it was a VERY buggy program called "Postgres95". With the 6.5 series, I believe it competes quite well with low-to-midrange databases from other vendors, such as, e.g., Raima. The speed is still about 10-20% slower, but for many applications that's not an issue, and the reliability and features *DEFINITELY* are there.

    I am probably stepping out on a limb, but here it is: the EST development team evaluated a variety of embedded databases for use in BRU Professional, everything from plain old 'gdbm' to embedded Oracle. PostGreSQL beat them all on features and reliability, and lagged only slightly in performance. It has taken five years, but PostGreSQL is a winner.

    Oh, my PostGreSQL wish-list:

    • Replication. Right now, replicating PostGreSQL databases is a pain in the @#$%@. I end up manually replicating them -- I have a 'modified' timestamp in every record, and my database routines timestamp that flag every time an 'insert' or 'update' is done to the database. Then I can do a simple query to pull out all the records changed between times and , and replicate that way. But that's a major pain in the @#$%@.
    • Hot Backups. Right now, we have to shut down PostGreSQL when it's time to back up the PostGreSQL databases themselves. Pain, pain pain.
    • Larger maximum record size. I believe 8192 bytes is the biggest record you can do with PostGreSQL at the moment. Doesn't bite me in my particular application, but someone who wants to keep big texts in PostGreSQL might be bitten. (This is being worked on, BTW).
    • Faster write speed! In fairness, this is being worked on. I haven't had a chance to benchmark PostGreSQL 7.0 yet, so I don't know whether the changes made it there.
    • *INTEGRATION WITH LDAP!*. I want PostGreSQL to be able to authenticate against a LDAP directory! This business of having both a Unix password, and a PostGreSQL password, is for the birds!
    Someday. Someday. Oh well, back to doing encrypted network connections again (sigh... talk about something that's a pain in the #@$%@ to debug :-).

    -E

  • While it is an ambitious plan, I definately think there is room for this type of service in the enterprise world. Great Bridge stands to benefit as do many smaller startups. If there is one area where the cost of enterprise computing is prohibitive its the database market. I work for a company of 40 employees and we have a $30,000 a year support contract for our database.

  • You can write stored procedures in PL/SQL, TCL, Python, or "C". How complex do you want to get?!

    Granted, this *DOES* need to be better documented. That's another lack of the PostGreSQL project -- very few of the advanced features are adequately documented. You should have seen how long it took me to get my first PL/SQL stored procedures working :-(.

    -E

  • I really don't like the idea of using a database where not even the developers have a firm understanding of the source;

    On the plus side, they claim they do understand it now. Its possible that the even the mighty Oracle's developer team doesn't know what everything does.
  • Ack, that was actually 3 paragraphs, wish this damn thing defaulted to text. Here's the properly formatted readable version:

    Finally when we isolate one of those nasty "That's the way our product handles it" kind of performance bugs we can fix it!! Oracle has a VERY nasty one where for every row in a parent table all children tables are checked for data that would prevent the delete (in a FK parent/child relationship) regardless of wether or not those tables were empty. We had a delete on a 35,000 row table that took 25 minutes on a SUN E4500 w/ 6GB RAM and an optical disk array with a HUGE cache (something like 16GB) even though we deleted the children table right before deleting the parent table. Placing indexes on the FK's fixed the problem but still, it should only have to check those tables once and see 'It's not empty' then stop checking.

    Maybe we'll actually have an enterprise-level database that allows us to fix ugly crap like that ourselves instead of waiting for some stodgy company to decide your particular issue is high enough priority.

    I just don't understand why more companies don't go Open Source. Yes, I know it's a scary concept letting everyone see your source but legally no-one has any rights to that source that you don't give them. Your competition cannot legally steal your work (though wether or not they could get away with it quietly is yet to be seen). Really it does nothing but make your product a better product and attract people like myself who love having the code handy.

    -Zane
  • my god this posting is superb!!! +5!!!
  • Any programmer who claims he understands all his own code -- let alone the code of others -- is a liar.

    Either the programmer's a liar, or he reviews and changes his code as he writes it so it's understandable later.

    Any programmer who doesn't understand all his own code is sloppy. That's why there are such things as /* #comments */.

    :wq!

  • Some may be interested in comparisons of the major Open Source databases. This article [linuxplanet.com] at LinuxPlanet has some good information.


    --

  • I sincerely hope that PostgreSQL is able to take off with the help of Great Bridge. It's a fine data base and I've learned a great deal about SQL Programming and Data Base Administration with it. It's a good learner's tool and you can't beat the feature set for its price.

    Still, there are some features that I'd like to see put into PostgreSQL that would make it far more marketable for a truly enterprise-class RDBMS:

    • Data Base Replication a la Oracle. This would make the data base significantly more scalable.
    • An extended SQL set to provide for more complex stored procedures.
    • Continued addition of ANSI SQL92 features (can't wait to see what's new in 7.0!)


    Personal rant here. One thing I like about PostgreSQL is that it's fairly easy to understand and administer. You have an idea of what's going on "under the hood". This is as opposed to Oracle which is great when it's working but otherwise tends to be mysterious as far as what it's doing. For this reason, Oracle is difficult for me to grok because it "feels" counter-intuitive.
  • Im aware of the ODBC driver, in fact I will depend on it.

    But... I need a way to populate the master database with the appropriate tables. That is what I need now.

    --John C
  • IIRC, Interbase was spun off of inprise. They aren't the same company anymore.
  • Foreign key * In 7.0 now. It's out of bet now and was released today.

    Outer joins were going to be in 7.1, but they changed the development cycle, and 7.1 is going to come around fast to add some other highly requested features, while 7.2 will have to wait a little longer.

    I'd have to agree with you though. I'm using interbase as well.
  • Basically, the reason MySQL gets more press is because most current use of Open Source databases is in the realm of Internet services, and MySQL is more useful in a CGI environment. Like most "real" Unix databases, PostGreSQL takes a while to establish connections, whereas MySQL is super-quick at establishing connections. Once connections are established things even out a bit, but if you can only accept 8 connections per second because that's all PostGreSQL can open, you pretty much rule out PostGreSQL as your web site's back end.

    MySQL is lightweight and very good at what it does. I feel somewhat ill, though, when I hear it called "SQL". It's not. It's a very limited subset of SQL, chosen in order to maximise speed, and it succeeds very well at that, thank you. But I wouldn't want to build an accounting package using it. Lack of transaction support alone, for example, immediately rules it out for "real" work.

    -E

  • I've evaluated Interbase. It is roughly equivalent to PostGreSQL, a few % faster at writes, about the same speed for reads, about the same foot print, about the same feature set (each has a few features the other doesn't have, but no big deal). But the thing is, its source code is not currently available, so that rules it out for use as a production Open Source database -- at the moment.

    _E

  • One reason companies are reluctant to release the source code to their products is because some components may (or may not) be patented. With the current screwed-up state of the software patent biz, code that's been in your product for 10 years might violate some patent or another (no matter how many patent-savvy consultants look it over), and you'll never know it until the attorney for the patent-owner sues you for half a billion dollars.

    A lot of closed-source vendors would feel a lot happier about releasing source for their products if they didn't fear getting their pants sued off for their efforts.

    -E


  • I vote for The OpenDB Project. It seems to fit the standard OSS nomenclature, sounds official enough, and most people will probably abbreviate it as ODB anyway: rapper or enterprise-level database? You decide...


    Dan
  • The page size is a compile-time option in PostGreSQL 6.5 and below.

    I don't know whether the limitation has been lifted in 7.0. It most certainly will be in 7.1, the guy in Russia who does the bottom end has been working on an entirely new storage manager.

    -E

  • At work I'm personally the owner of code that nobody understands. If there is ever a bug in that code, or a feature required I will have to fix it. That code was last touched several years ago, by the person who wrote it that week. He is a better programer then me, I have no hope of writing a couple hundred lines of bug free code as quick as he did.

    Point is, if it ain't broke don't break it. The code does it's job. I don't see the point in changing it until I have to port it to a different platform. Even then I wouldn't be surprized if it was a simple re-compile.

  • I don't think most long-time OSS users are ready to trust Inprise (or Corel if that happens) as a reliable OSS vendor just yet. Senior mgt. at both companies have been at pains lately to assure the markets that they intend to make their money through retail sales of a mainly proprietary product set. It's OSS now, but what about 6 months from now?

    I happen to like the Inprise product set, but I wouldn't make it a first choice on a project today, if software freedom was important to the project's successful outcome.
  • I don't even know why I am responding to this. I guess it is because I waiting for a big download to finish.

    Funny how you are quick to point out how it's unrealistic to expect programmers to understand every aspect of their code, but then seem to support the idea that before microsoft there was "stable" software. Software engineering sucks, inside and outside of Microsoft.

    I do expect developers to understand every aspect of their code but not every aspect of others code! There is a difference.

    There is also a DIFFERENCE between stable software and programmers understanding every aspect of the project they are working on.

    I've worked on projects where not one of the developers, including the tech lead, understood every aspect of the code but it was incredibly stable!

    Well my download is complete so I am going to stop wasting my time.

  • by Jason Earl ( 1894 ) on Tuesday May 09, 2000 @06:31AM (#1083333) Homepage Journal

    The PostgreSQL team has come a long way. They inherited a codebase with known bugs and some fairly serious failures. They have worked hard and have turned the quirky Postgres of yesterday into a powerful and dependable tool. Anyone who has used past versions of Postgres will tell you that the latest versions are a completely different beast.

    PostgreSQL 6.5 has been out for nearly a year, and the 7.0 release will be out any day. In fact, I am currently running one of the release candidates in production because of the added performance. PostgreSQL has a full set of reqression tests, a rich set of features, a dedicated development team, and an extremely helpful mailing list.

    What PostgreSQL doesn't have, however, is a marketing department that is going to feed you pap. The developers are perfectly willing to tell you which parts of the database are in a state of flux. Historically the list of features that were less than stellar was fairly long, but that is no longer the case. The flip side of the PostgreSQL team's honesty is that, when they tell you that a feature is ready for prime time, you can bet that it is indeed ready to be put into production. How often have you put commercial software to the test only to find that some of the new features are lacking? With PostgreSQL there is no guessing which parts are ready to go.

    Clearly the PostgreSQL database isn't right for everyone. But it's no slouch either. And you only As I mentioned before I am currently using it in production and am quite happy with it. I have several tables with millions of rows in them and performance has been more than acceptable. I have been very impressed.

    The PostgreSQL mailing lists are full of developers that have migrated from MySQL. MySQL is great for 90% of database tasks, and it has the advantage of being very fast at straight selects, but if you need ACID features then MySQL isn't going to get you there. PostgreSQL will, however, and it also throws in a raft of useful features like triggers stored procedures (in 4 different languages including Perl and Tcl), views, etc. PostgreSQL's support of subselects could very well improve your application's performance.

    Not too mention the fact that PostgreSQL is truly Open Source (BSD style license) while the current version of MySQL is clearly not. That is why you get announcements like this for PostgreSQL and not for MySQL.

    I am a bit skeptical about this particular announcement myself (since I hadn't heard anything to this effect on the PostgreSQL mailing lists), but whether this particular venture pans out or not it will almost certainly mean that some more PostgreSQL code will be generated.

    Heck, it might even make it into 7.1.

  • ok, the title looks a lot like offtopic, and you may rightly ask how Ill try to get on-topic again.

    look:

    something that Linux lacks right now is a log-structured filesystem (the newest Solaris has, if Im not misinformed). I consider this a requirement for an absolutely mission critical system. But Linux, the free software, is rapidly closing in to Solaris, its commercial counterpart (journaling reiserfs, later log-structured filesystems, too). It wont be too long until it is on par with Solaris.

    Now, with Postgres I see the same. Its a lot less on par with Oracle that Linux is with Solaris. Perhaps this has to do with the fact that more people want a free Unix than a free DB. However, this is changing, since DBs get more and more important.

    The point is: I suspect that Postgres takes the same course as Linux: The free software will get on par with its commercial counterpart. Postgres will just arrive there a little later.

  • Or know where to find it?

    In their rush to chuck newer, faster versions of SQLServer on the market they tend to concentrate on the speed rather than the reliability.

    This isn't a flame, but do you know where I can find data to back-up this statement? I can't find anywhere that documents the actual reliablility rather than speed of databases.

  • Agreed. What I'd like to see is a core database which had a neat protocol for plugin enabling. Integrated services may be faster, but nevertheless they can be a pain when you don't need them. Look at Mozilla - what most people want is just a super fast browser, if we want mail and what-have-we, we'd download their plugin.
  • by Zico ( 14255 ) on Tuesday May 09, 2000 @06:34AM (#1083337)

    I've written code of which I only have a vague understanding [...]

    Inquiring minds want to know. It was in Perl, wasn't it? :)

    Cheers,
    ZicoKnows@hotmail.com

  • What worried me about Postgres was that they claimed that before 6.5, there were some sections of code that NOBODY on the development team understood.

    Look, not knowing crap about databases and large software projects is okay. That would explain why you got scared by reading something that happens in probably all large software projects. An RDBMS is not a "Hello World" for goodness sake !

    The MySQL team probably would never admit this because they don't even understand what ACID means and because if they lie to people saying that speed is better than reliability, they would lie about this too.

    The bottom line is that MySQL is just a file system with an SQL interface. That's it. If you want to play databases, go with it, but please post here if you ever do anything public with it so we never buy anything there.

    PostgreSQL has been improving vastly and constantly. Release 7 comes with lots of optimizing changes, bug fixes and foreign keys. PostgreSQL is almost 100% ACID-compliant. The MySQL implementors don't even know what that is, rather try to implement it.

  • Its possible that the even the mighty Oracle's developer team doesn't know what everything does.

    I've seen Oracle copyright notices going back as far as 1975 or so, which implies that their codebase is 25 years old. Are any of the original Oracle developers still on the team? How many of their current developers have even been there more than 5-10 years?

    Couple a large project with even modest turnover, and you're bound to have sections of code that few (if any) current developers are familiar with. It's probably almost unavoidable. Why do you assume that commercial databases don't have the same problem?

    At least the PostgreSQL developers admit they didn't fully understand the code they were maintaining until more recently. They say they are familiar with all of the code now. Chances are that puts them ahead of Oracle in that regard, not behind. Keep in mind that PostgreSQL derives from Postgres95, which derives from Postgres, which was an academic research database. That's a long history to catch up on. Give them some credit for managing it at all, and for being honest about their progress...
  • by Ektanoor ( 9949 ) on Tuesday May 09, 2000 @06:54AM (#1083350) Journal
    It looks that we are getting too much biased on the prospect of all-open-source "bright future". As one poster noted, we don't need Postgres for being a kill-app. Frankly I am no big expert on database managers but here there are a lot of people that work and study several databases managers. Starting with MySQL, Microsoft SQL, PostgresSQL going up to Oracle, DB2 (and even running over other, non-relational, database systems). And I respect their general attitude to these systems, as they have a big professional experience. They mostly scale RDBMS in this way (on growing popularity/manageability/features):
    1. MySQL and alikes - fast and simple database systems. Mainly for a work on the run
    2. Microsoft SQL Server - In a "one database" "dedicated" system it rules. However most of them don't like it because every work usually ends in "several databases" and most systems don't run only a SQL server.
    3. PostgresSQl - powerful database system but it still has a long way to go. Specially on what concerns its management and features. Along with it some put also Borlnd's Interbase.
    4. Oracle & DB2 - High profile database systems. They are the real rulers around here. Specially on what concerns Oracle. They have most things a database developer needs for large databases and their management. However their last versions have become quite "bloated" with features that presently most people consider quite superfluous.

    No matter its open-source nature, Postgres is second on the row, along with Interbase. And looking at the comments of most people this is highly accepted as a fact. However I have noted that the "big ones"have become too fat. Besides their price has has being run from astronomic to intergalactic. So people now I see people turning their eyes to Postgres. But not only. MySQL, no matter its primitivness, has run from a near outsider to the second most used system in my neighborhood. Soon it may turn into the most popular RDBMS. For Postgres to run from third/fourth RDBMS into first place, it will need to be more manageable, more well-documented and to have a good support in all sort of interfaces and client systems. And it will have to include some of the features included on DB/2 and Oracle. When they will manage to do this and avoid the present "bloatness"of the major runners, then Postgres may become a kill-app. Until then, it is just a very cool and Big database system. No matter being open-sourced.
  • No, they don't need to release any changes they make, but from the interview, they plan to be a largely service oriented company. I.e. they will provide a packages PostgresSQL with shiny add-ons like printed manuals and technical support. They must realize that if they want to get the support of a developer community, they are going to have to give back.

    Dana
  • by Mr. Slippery ( 47854 ) <tms&infamous,net> on Tuesday May 09, 2000 @06:56AM (#1083355) Homepage
    Any programmer who doesn't understand all his own code is sloppy. That's why there are such things as /* #comments */.
    Even well-commented code isn't fully understood immediately if you haven't looked at it for a few years. What well-written and well-commented code helps you do is get that understanding back rapidly when you pick it up again.

    The best-commented code is where, just as the reader starts to ask, "What the heck is this?", there's a comment right there that answers the question. But the only way that there's not even a question is when the code is trivial.

  • I've been working with Oracle dbs for 10 years now and whats annoyed me more and more since around v7 is the continuing 'bloat' thats going into the product.

    Some areas, such as database replication, table partitioning and direct loads are useful. Others, such as java integration, web features etc are not. They may offer an easier path for developers to get data to where they want it, I admit, but methods not much more complex existed anyway

    I guess the real gripe I have about these areas is the impact they have been having on Oracle support which is slowly going down-hill. Unless you have the (mega) bucks to pay for gold support the response you get from front-line support people is getting worse and worse. A while back you could guarantee that the person you got on the end of the phone at the first call had some knowledge of DBA work in a production environment. Nowadays I sometimes feel like I'm speaking to someone who wouldn't know how to connect without a GUI. I'm convinced that Oracle is pulling more and more resources into these 'e-fads' and away from basic RDBMS development and support.

    Postie just might be able to pull things back to where they should be, fast and secure data storage and retrieval.

    The other obvious area Oracle falls down on is administration. There are damn few really good DBA's around and without one even the simplest app can fall over on performance in a badly configured environment. There is no 'out of the box' solution with Oracle, its all very much a matter of knowing the insides of the beast.

    A side note, Oracle is stable on features that have been around for a while but its down-right dangerous on new areas. Check the bug lists on partitioned tables for a laugh, or on parallel query execution. The cost based optimiser mode which was intended to make performance tuning SQL eaiser took from v7.0 to v7.3 (a number of years) to become close to stable. Only to be near superseded in Oracle 8.1 (Oops Oracle8i, that is - another bad sign, suddenly departing from normal version numbers for no apparent reason).

    Basically, get me back to basics. Data in, Data out, Real Fast. And make tuning as 'black box' as possible without removing the possibility of tweaking it where its needed and I'll be well happy using Postie.

    ZamZ (these opinions are my own, I think)

  • Almost no one care about Databases Per-say.

    What people care about is the data and the ability to have code that gets the data, plays with the data, and outputs the results.

    An example is Oracle Finactionals. It is an accounting package. Once you have your accounting package on database X, you then can intergrate all your other stuff into database X.

    If PostgreSQL wants to take on "the big boys" they have to be willing to back an accounting package. Get a good-quality accounting base, and users will add ties for POS, Inventory, etc.
  • the big question i have (paranoia alert!) is that PostgreSQL is under a BSD license, so they don't need to release any changes...

    If they try to make it proprietary, someone will just fork off the last open version and leave the proprietary version in the dust. Two examples would be OpenSSH and XFree86 (the threat to proceed independently under an open license kept X11R6.4 open).
  • Actually Sendmail is BSD code, as is Apache, as is (obviously FreeBSD). All of these have commercial arms of some sort. They also have managed to stay in charge of development despite the fact that their projects could be forked (and could even be forked under a GPL style license) if they got lax in updating.

    There is no question that the GPL ensures a certain amount of safety to the consumer, but it is certainly possible to have truly open BSD projects. BSD licenses are probably a little more reassuring for investors as well, because they maintain the option of making proprietary extensions. BSD licenses have their own set of problems (for example, they can't accept GPL or LGPL code), but it's nothing that a diligent Free Software advocate can't handle. Stick with the freely available software and you'll be fine.

    Besides, if the project does get off track you can always take the last BSD licensed version and fork the code. You can even release your extensions under the GPL and create was is essentially a GPL version of the software.

    Note: don't try this with the current PostgreSQL team, however. GPL software will not make it into PostgreSQL (although it might make it into contrib).

  • postgresql is process-per-user - the engine isn't multithreaded. this is a scalability issue for apps that produce a large number of connections.

    Given that Linux process switching is faster than Solaris thread switching, I can't see this being a terrible problem for Linux (and you can bet your butt Linux isn't the only fast-switching OS in the world).

    Apache on Linux kicks butt at high loads with thread-per-user (at least, it does since it got wake-one to play with).

    PostGreSQL on NT, however, would run like a dyslexic centipede, given the truly staggering per-process overheads there. What a shame.

    Actually, it seems to me that threading under NT is a kind of a conceptual bandaid to slow the bleeding of their whole-process issues.
  • You can either pay per user OR per power unit. In fact you can pay for a two year license and get a low entyr price. Considering the upgrade cycle for most software is two years anyway I'd say this is the way to go. If you have a 500 Mhz server a two year licence will cost you $2500.00 double that for a dual pIII 500 box. Not bad considering you are getting the best database on the market bar none.

    I figure in two years nobody is going to be able to charge for a database though. Postgres is already pretty good and getting better and interbase is pretty damned good from the getgo. Unless you are running ebay or something there is no need to ever pay for a database.
  • No compromises. If its free, it must stay free, and noone is permitted to make it proprietary.

    And if someone calls the GPL a "virus", he obviously wants to unfairly take advantage of other peoples work without contributing anything by himself.
  • Right now, I would kill for an open source database that I could connect MS Project clients to.

    I know it might be contrarian to support a MS tool on the client, but hey lets face it. Right now, geeks like me control the data center but not everyones desktop. Breaking the MS Stronghold in the data center / server arena is the first step then we conquer the desktop. [Remember we need to fight using similar tactics to what Microsloth uses]

    If PostgreSQL supported MS Project 2k I could get my whole division to move to using it as the backend database server since we would not have to pay licenses for the database. From my current understanding all I need is the sql to create the tables in Postgres. The MS Proj cd ships with the sql to create the tables in MS Sql Server, Oracle & Access but I havent been able to get them created in Postgres. Any ideas???

    --John Cavanaugh
  • I spent last christmas hacking a websystem together in java, with PostgreSQLas db.

    PostgreSQL may have come a long way, but it's definitely lacking. Esp. a working and complete JDBC driver.

    • The manual tells you about how easy lobs are with getAsStream() but when you use those functions you get a "Not implemented" error. GREAT! Fortunately there was a LOB handling through custom classes, but it didn't work as advertised and a manual that lies to me is very frustrating.
    • All data coming into JDBC are strings. Fine. But the date conversion doesn't work if you live in ECT/CET. So you have to parse the string yourself. You tell the author of the JDBC driver and he says "Oh didn't know that, I'll look at it." Haven't heard from him since. Last jdbc driver update was September 14 1999, jdk1.2 only.
    • Lots of stuff is not implemented in the JDBC driver, like the meta stuff.
    Then postgresql itself.
    • Limited tuple size, limited query size (8k each) in 6.5.3.
    • One failed operation (say, an insert) will abort the whole transaction, all the previous work also.
    • LOB migration (to other db installations) was only possible by writing a whole application.
    • The docs suck, the mailing list interface even more, searches don't work.
    Mysql may suck, but it's a good at that.
  • Interbase is open sourced and is available today.

    Really? Where is the source? So far, Interbase source has been promised, but to my knowledge, never delivered.
  • Oracle, perhaps not. But how about Microsoft? Or Sybase?
    --
  • by nedlilly ( 121152 ) on Tuesday May 09, 2000 @08:29AM (#1083380) Homepage
    Greetings all,

    Wow, we're happy to see the response to the initial announcements. I'm Ned Lilly, one of the four employees mentioned in the CNET/Yahoo article. Wanted to say hey, and try and answer some of the questions I've seen so far. Pls feel free to email me directly too- ned@greatbridge.com.

    1) PostgreSQL Features. We took about six months to study the open-source world, and have spent a lot of time testing, benchmarking, reviewing code, etc., and in our opinion, PostgreSQL 7.0 is by far the best choice among open-source databases. My personal impression is that some people might have bad memories of earlier versions (I myself actually used it in an earlier business but had to throw it away), but the improvements leading up to 6.5.x and now 7.0 are incredible. And, of course, 7.1 is going be even better :) I'd defer any specific questions about features to the Postgres developers themselves (http://www.postgresql.org/devel-contrib.html) - they're still running the development effort, and will continue to do so.

    2) MySQL & Interbase. So that begs the question, what about other open-source databases. Don't want to start a flame-a-thon here, I'll just say that we think MySQL lacks a lot of desirable features (this topic's been exhaustively debated elsewhere), and Interbase, while it might be a good commercial product, isn't yet open-source. To my knowledge, they haven't released the source for 6.0 yet (only binaries), and it's a fair question whether you can create a robust open-source community instantaneously. PostgreSQL has been open-source for many years, and the current core steering group has done a great job at making the code base clean, uniform, and accessible to other hackers.

    3) Our Customers. So who are our customers? There's been some good discussion here on that topic already. The short answer is, we've got some ideas, but we're being fairly deliberate in how we verify those ideas. We've done some pretty comprehensive market research on different sectors of the IT world, including 32 focus groups in four U.S. cities, and we think we'll be able to put PostgreSQL (and other open-source tools) in the hands of the people who will best be able to use them. We don't really want to talk in too much detail about our business model at this point - frankly, we're still refining it based on the potential customer feedback we're getting from this research. That process is how Landmark Communications (the parent company) went about building The Weather Channel cable network from scratch, and we think it can set us apart from some of the other open source companies in the market today.

    4) BSD vs GPL. More potential flame-bait here, so read carefully... :) Another area we spent a lot of time researching was the area of open source licensing. We like the Berkeley/BSD-style license under which PostgreSQL is now offered; we think it's the simplest to understand (it's free for any use, with no restrictions on what you can do with the code), and offers the fewest barriers to widespread commercial adoption. We've heard from a lot of business types that a GPL-style license scares them when it's touching their proprietary business applications. You might wonder if we're just going to freeload on all the community development work, then take the code, call it GreatBridgeSQL, and fork it off into some proprietary product. That would be the stupidest thing we could possibly do - we are 100% bought into the open source development model, and have no intention of ruining what is working so well. Indeed, we're going to do quite a bit of internal development ourselves - on interfaces, APIs, monitoring tools, and business applications - and everything we write, we're going to throw back over the fence into open source for the community to bang on and improve. We'll do the same to other peoples' code - just like any other member of the community.

    5) Business Plans. Some of the press reports have talked about a potential IPO, and people have rightly sniffed and said, yeah right. Let me be perfectly clear on this one: Landmark Communications, which is a 100-year old privately held company, doesn't build companies to do a quick public offering spin-out. The Weather Channel, and weather.com (which has 14 million unique users a month), are both privately held. Great Bridge's CEO, Al Ritter, is the former CFO of Landmark corporate, and is deeply steeped in the old-fashioned notion that companies should probably try and be profitable rather than just ask for more and more public money. We have no intention of going down the IPO road until we're satisfied that we've built a business that can stand on its own two feet, generating real live profits by delivering professional support for open source software solutions. We think, frankly, that a lot of tech support (particularly in the database arena) stinks - and we can do better. We think we've got a good product to get behind in Postgres. And if at some point down the road we think there's an opportunity to super-charge the business through an IPO, we might well do it. But unlike a lot of startups, we don't need the money. Landmark's committed $25 million to this phase of the rollout, and if we can make the case to our corporate bosses for another round of investment, there's more where that came from.

    6) Hiring. Yup, we're hiring. We want developers, support engineers, even, er... marketing people. We're talking with a lot of people in the PostgreSQL world already, and will be making some more announcements on that front in the weeks to come. If you're interested, please email me at ned@greatbridge.com.

    Thanks...
    Ned


  • I've worked on Enterprise level applications most of my working life, the largest being 10 year Air Traffic Control behemoths. Not having someone who understands all of the code is an indication of a large scale system. It doesn't mean that there isn't an understanding of the source but that the understanding resides in several heads. IMO this is better than having it just in one.

  • by maddboyy ( 32850 ) on Tuesday May 09, 2000 @05:47AM (#1083383) Homepage
    These guys don't need to compete with Oracle, DB2, Sysbase or any other enterprise class database. There's a huge market for people needing/wanting a full RDBMS system for small/mid-level database work. PostgreSQL fills this niche nicely. It passes the ACID test; has fairly decent ODBC, JDBC, Perl DBI, and PHP support; acceptable speed performance; and all of the benefits of being an open source project. Now that it will have Great Bridge doing development and offering commercial support, companies will be able to get reliable(read blammable) support for this product. This is great for more open source penetration into the corporate world.
  • by Carnage4Life ( 106069 ) on Tuesday May 09, 2000 @05:48AM (#1083387) Homepage Journal
    From the article:
    As chief financial officer of media company Landmark Communications, Ritter watched his company miss out on a golden opportunity to invest in Linux software seller Red Hat way before its successful initial public offering. Now he hopes to catch the second wave of the open-source software trend.
    ...
    Great Bridge, though consisting of only four employees today, has grand ambitions, including a planned expansion to 120 employees and the ultimate possibility of going public, Ritter said. But the biggest challenge will be taking on giants such as Oracle, IBM, Microsoft, Informix and Sybase, each of which have their own proprietary database programs.


    First of all, a proclamation like this seems to me more like jumping on the open source bandwagon and hoping for a successful IPO (with no long term prospects of giving investors return on their value) than as a project that is destined to make Oracle and Sybase quake in their boots. It is particularly interesting that the a company that is supposedly Open Source oriented is stating all sorts of plans about IPOs and such and little or no talk about technology.

    Hopefully I am wrong and this will be a company that will give back to the community in spades as opposed to a bunch of opportunists. Oracle databases currently cost several thousand dollars ($20,000 minimum price) while MSFT's cheap SQL server is about five thousand dollars. If a company can be created that will produce software as robust and functional as Oracle software (believe me that is a daunting task) and yet charge only support costs they may well sweep the DB market especially for small businesses. Of course, it will take a phenomenal amount of work (mayhap an impossible amount) for a four man company to compete with a company that has $6 billion in revenues and one of the most robust products in it's area. I wish them luck.

  • Relational databases are big and complicated monsters (at least the ones for high end use). Many have hardware optimization code ala Quake(I/II/III)..except instead of optimizing for vector math and graphics card it's optimized for search queries and i/o hardware (I know Oracle even offers to use unformatted disks on it's own to avoid slowdows caused by having a filesystem to interact with). Plus it includes a command interpreter (SQL), etc. You could go on for a long time regarding all the libraries, drivers, etc. used by a full RDBMS, and I wouldn't be suprized if it approaches or exceedes the complexity of developing a feature rich OS.

    Now, do you think there is one developer that knows every piece of code in WinXX? MacOS x.x? The xNIX kernel (including ALL modules)? No, not everything. . It is how well these teams work together to produce a cohesive product that really counts.

    disclaimer: I am not a developer much less a development project leader, though if someone actually does (could) know all that information, I would be really impressed :) .
  • We can call it something nice and corporate like:
    "We?" I didn't see your name on the developer list! (-:

    I was using the editorial "we", speaking in my in my capacity as the sole developer of my proposed fork of the Postgresql code. I don't believe I'm required by the license to even give the Postgresql developers any credit.

    (So it goes with the BSD style licenses... Some of the people on the Postgresql hackers list were saying that they'd like to take a look at the Interbase code when it's really opened up, if only to check and see how much of they're code they lifted from earlier versions of postgres...)

    Anyway, I like the name Greased Piglet. In fact, that was another idea I had kicking around, to try and get everyone to use the nickname 'gres, pronounced "grease". Postgresql jocks are then "greasers".

  • I'm not suggesting it's a conspiracy. My point is that Interbase looks very promising, but the source isn't available yet, so it's misleading to describe it as an "available" open-source alternative. It will be nice to see it released, but until then it's a red herring. (Sure, you can get a binary-only beta, but you can get free binaries of Sybase for Linux too.)

    The annoying thing about open-sourcing formerly proprietary products is that nobody ever bothers to release the source for existing releases. It's always a pre-release of the next big release. I understand it's more work, but the people who bought the proprietary releases of the products would probably like to be able to get the source code and improve it without being forced to use the newest release to do so. (This all applies to Netscape as much as Interbase.)
  • Oracle databases currently cost several thousand dollars ($20,000 minimum price)


    Bzzt - Wrong. A five users license costs around $800.

  • If it's a simple matter of making MSSQL work with Postgres' (or some other databases) SQL implementation, this shouldn't be *too* tricky.

    Maybe it's possible, who knows? The point is, you can't get any help unless you put the SQL out there for someone to have a look at it. If that doesn't violate the license, of course, but hey - they wouldn't have given you the SQL source unless they expected you to be able to do stuff with it...
  • How many people actually need these features more than just a standalone

    The answer: lots.

    If you do lots of complex querying, you need a syntactically powerful SQL with various kinds of subqueries and outer joins.

    If you have to run transactions against multiple machines, you need two phase commit.

    If you need to reconcile needs for high transaction volume and high consistency, you need Oracle's ability to isolate selects from incomplete transactions.

    If you've reached the point where you can't just throw faster disks at a problem to handle your transaction and query volumes, you need table clustering and raw file systems.

    If you need 7x24 operations, you need hot backups, the ability to move tables to different devices and make schema changes while the database is running and accepting transactions.

    Midrange and low end databases are sprouting some of these kinds of features, but Oracle has it all. Anyone who sees Postgres or Interbase or MySQL as an Oracle kiler is smoking crack.

    Each of these products has its place, and may very well limit Oracle's penetration into the low end market and erode its position in the mid range market. But you aren't going to be doing an airline scheduling system or an accounting system to support a fortune 500 company on Postgresql any time soon.

  • But if you haven't ipo'd lately or aren't a multi-millionare company.. you can't go buying that type of equiptment.

    Or if you are H&R block, chances are you might not need this either.

    ---

  • ...when Interbase is on its way...

    Interbase is an ex-proprietry database solution which is (we hope) becoming open source. It runs under Linux, and Win32. In a recent Linux Care poll [linuxcare.com] it came top of the list of databases for most, if not all areas. It already has a solid userbase including NASA, Boeing, and is even used in the M-1 Abrams Tank.

    Granted, the source has not seen the light of day, but 'should' be on its way soon.

    Interbase provides a very firm stand point launch the open source development. There is an open source documentation project underway Links :
    Interbase Homepage [interbase.com]
    Developer Initiative site [interbase2000.org]

  • I believe I didn't explain what I meant clearly.

    What worried me about Postgres was that they claimed that before 6.5, there were some sections of code that NOBODY on the development team understood.

    I understand that in most large projects, there isn't the one guy that understand all the source. But for any given module of chunk of code, there should be at least one developer (and hopefully many more than that) that understands the code and knows how to maintain it.

    Perhaps bumping the developer count to 120 will remedy this; let's sure hope so!
  • The AC makes a valid point about TPC tests. For the past few months, we've been building a lab which is, as we speak, running the TPC-C and TPC-D tests, as well as the AS3AP tests - pitting Postgres against other RDBMS products, both open and proprietary.

    I think the results will surprise a lot of people.

    Once we're done with the tests, we'll then look to get them duplicated and certified by outside parties in the press as well as TPC itself.

    One fun little factoid we discovered: Some proprietary vendors [microsoft.com] include a little provision in your software license that forbids you from releasing benchmark information naming their product without their permission. I hereby promise a veritable public relations carnival to highlight that fact.

    Regards,
    Ned Lilly
    VP, Hacker Relations

  • So what it boils down to is, if you open-source the existing version, you cause all the existing inventory at the distributors to have a value of zero; this constitutes damages, and is probably actionable. Expect your pants to be sued off shortly.

    They could refund money to the distributors for any returned copies they haven't sold yet. Or they could simply say that the "end of life" for the product is (some deadline) and promise to release the source once that deadline is past. Old products don't have much value anyway...

    If nothing else, couldn't the first open-source version be the minimum cleanup necessary from the last proprietary version, not a development version with lots of half-finished features?

    And whatever happens, you'd better do a flawless execution of your open source business plan, because the bridge you just rode in on is now merrily in flames.

    Descriptive analogy. Quite true, of course.
  • by DanaL ( 66515 ) on Tuesday May 09, 2000 @06:00AM (#1083436)
    I always thought databases would be a good candidate for Open Source development. Since many (most?) of the users are developer-minded already, getting a community should be easier than getting people to rally around it.

    What I *hope* this new company will do, if it truly emmulates RHAT, is hire full time developers for the project. Hobbiest coders have contributed tons to linux (heck, they invented it), but I'm sure the OS has benefited immensely from having full-time people working on it as a day job. I'd like to see the same for postgress.

    I also agree with the other commenters who point out that postgress doesn't need to be an Oracle killer. There are plenty of medium to large projects that don't require a full scale Oracle system. Postgress can become an important alternative for people who need more than Access (or, arguably MySQL), but don't need Oracle and don't want to use SQL Server.

    My $0.02 :)

    Dana

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...