Forgot your password?
typodupeerror

Top 5 Reasons People Dismiss PostgreSQL 704

Posted by ScuttleMonkey
from the dispell-rank-2006 dept.
Jane Walker writes "In an effort to dispel some of the FUD surrounding this impressive product, this article puts forth several of the most commonplace reasons for a user to dismiss PostgreSQL." From the article: "While PostgreSQL's adoption rate continues to accelerate, some folks wonder why that rate isn't even steeper given its impressive array of features. One can speculate that many of the reasons for not considering its adoption tend to be based on either outdated or misinformed sources."
This discussion has been archived. No new comments can be posted.

Top 5 Reasons People Dismiss PostgreSQL

Comments Filter:
  • Availability (Score:5, Insightful)

    by Anonymous Coward on Tuesday March 14, 2006 @11:21PM (#14921520)
    MySQL is pre-installed by most webhosts, and does the job for most tasks.

    First post?
    • Other things... (Score:5, Insightful)

      by Saeed al-Sahaf (665390) on Tuesday March 14, 2006 @11:27PM (#14921549) Homepage
      Indeed. And once most people are familure with MySQL and the various tools and language support, there tends to be little reason to switch. PostgreSQL is a better database product, but many (all?) of the features that it's cheering section continue to tell us all about whenever the issue comes up, are simply not ones that the majority of MySQL users want or need. Maybe PostgreSQL fans should target Oracle usres.
      • Re:Other things... (Score:5, Insightful)

        by jadavis (473492) on Tuesday March 14, 2006 @11:50PM (#14921682)
        What about consistency? I talk to people all the time who are befuddled by MySQL's lax type checking. I know it's been hashed out before on /., but February 31st is NOT a date, and does not belong in any column named "date".

        If your application has an bug and inserts an invalid date, you don't want that error to cascade to another application (or another part in your application) and cause more errors down the line. By the time you detect the bug, it could be almost impossible to determine the source of the bug.

        Putting consistency checking in application A doesn't prevent application B from inserting invalid data. And when application A reports an error (due to it's wonderful in-application consistency checking), now you don't know what caused the error. It's long past the time that you can get meaningful state information from application B, at most you have database auditing tools that tell you "application B did it", but that's more easily implemented in PostgreSQL as well (triggers).

        And I'm not talking about super-advanced users only. I am talking about everyone who wants to catch the error early when they have the most possible information. Everyone who's just a programmer who wants to be able to trust that data from the database comes in a meaningful form. Everyone that just wants the database to do either what they expect, or throw an error.
        • by Anonymous Coward on Wednesday March 15, 2006 @12:32AM (#14921891)
          I talk to people all the time who are befuddled by MySQL's lax type checking.

          That's why I use SQLite. Its lack of type checking is so profound, nobody has a problem grasping it!

        • by Gnight (163400) on Wednesday March 15, 2006 @12:35AM (#14921900)
          ...February 31st is NOT a date, and does not belong in any column named "date".

          You're just jealous that your year is shorter than mine. Don't hate on me because I refuse to recognize calendars that skip days. 31 days in every month. It's gotten me in a little trouble at work though...

          Isn't this fixed in recent versions of MySQL anyways?
          • Re:Other things... (Score:5, Informative)

            by jadavis (473492) on Wednesday March 15, 2006 @12:41AM (#14921926)
            Isn't this fixed in recent versions of MySQL anyways?

            In the last thing I installed which is whatever came from the FreeBSD ports collection, it was still a problem. 4.1 I believe.

            As MySQL gets a lot of flack for this poor design philosophy*, they have come up with "strict mode" as a solution. That's a configuration option that is more strict about reporting errors. It's a step in the right direction, but that makes it wildly imcompatible with many MySQL applications.

            So it's "fixed" in the sense that you can optionally break backwards compatibility to fix it. I haven't heard many reports about people actually trying to use strict mode.

            * MySQL has backtracked on design philosophy before. Remember back when an ACID transaction was evil and slow and MySQL would never implement transactions or triggers or anything else?
            • Re:Other things... (Score:3, Informative)

              by dfetter (2035)
              Just one teensy little problem with "strict mode:" any client can turn it off! Somebody is unclear on the concept of Codd's 12th rule.
              • Re:Other things... (Score:5, Insightful)

                by jadavis (473492) on Wednesday March 15, 2006 @04:50AM (#14922649)
                Excellent point. That breaks isolation, and a bug in one application can still cascade problems into other applications.

                In particular this is likely to allow security problems in the application to cause malformed data to be entered into the database, thereby affecting other applications.
          • by Lispy (136512) on Wednesday March 15, 2006 @05:30AM (#14922726) Homepage
            Basically once I retire I have this scheme to sue all sorts of companies for getting paid on a monthly basis but providing less service in February or even in a 30 days month. This should keep me busy til I die and sounds like a fun petproject to manage from my couch. :)
        • Re:Other things... (Score:5, Insightful)

          by adolfojp (730818) on Wednesday March 15, 2006 @12:41AM (#14921927)
          I "inherited" a badly designed MySQL database that a couple of developers were shoveling data into with their nifty little apps. Empty dates were sometimes NULL and sometimes 0000-00-00 and sometimes something else. Also, since it was designed with MyISAM tables there was no referential integrity and there were countless orphans. I am so glad that it was not a database that dealt with bank accounts.

          MySQL has never cared about enforcing database integrity and are just starting to do so. The sad part is that the vast mayority of the people that use MySQL because it is the default database don't fully understand what data integrity or consistency is.

          Cheers,
          Adolfo
          • Re:Other things... (Score:3, Insightful)

            by jadavis (473492)
            MySQL has never cared about enforcing database integrity and are just starting to do so.

            Yes, the fact is that MySQL is trying to adopt a more PostgreSQL-like philosophy, using their market share and name recognition. In the meantime, the current users are in for a rough ride of backwards-incompatibility.

            So, the question is, does MySQL get PostgreSQL's features and philosophy in place before PostgreSQL get's MySQL's market share in place?
          • Re:Other things... (Score:4, Informative)

            by hackstraw (262471) * on Wednesday March 15, 2006 @01:37AM (#14922126)
            I "inherited" a badly designed MySQL database that a couple of developers were shoveling data into with their nifty little apps. Empty dates were sometimes NULL and sometimes 0000-00-00 and sometimes something else.

            I "inherited" a badly written C++ project where an integer was to be displayed as ASCII text, and the data structure was a character field, and not an integer. Oh, sometimes the number was stored as hex or base 10. Now, the cute part was that this excellent programmer converted the datatype to and from base 10 and hex, and his exhaustive testing apparently never went past 10.

            Now, this code was copied and pasted about 3 or 4 times for different modules like admin or customer or something like that. And each one was subtly different.

            My point is that the tool is not always the problem. Now if C++'s integer arithmetic had an issue, that is another story, but the programmer simply was not good.

            Now, MySQL is not a very logical or robust DB at all times, but it is documented, and any competent programmer could have gotten around the 0000-00-00, NULL, and "something else" things.

            I checked some of MySQL's date functions, and one of them does this:

            mysql> SELECT CURTIME();
                            -> '23:50:26'
            mysql> SELECT CURTIME() + 0;
                            -> 235026


            That is weird. The curtime value in numeric context is only good for comparison to another valid curtime() whatever, but it can't be added or subtracted as an integer. Yes, MySQL _should_ make date fields something generic xor NULL, or a valid date, not Feb 31, 2000, but its something that needs to be done at the programming level. Personally, I always use UNIX timestamps (seconds since 1970). They can be directly added, sorted, and converted into any timezone, and its very portable. But thats just me. (Yes, UNIX timestamps do nothing before 1970, etc, etc).

            • Re:Other things... (Score:4, Insightful)

              by adolfojp (730818) on Wednesday March 15, 2006 @01:52AM (#14922172)
              Yes, MySQL _should_ make date fields something generic xor NULL, or a valid date, not Feb 31, 2000, but its something that needs to be done at the programming level.
              A database should enforce certain rules so that its data will not be compromised. It must not allow bad external code to destroy its integrity, otherwise, it will be worthless for important applications. That is the purpose of features like stored procedures, constraints and trigers. MySQL has those features, but it is still missing some details like type consistency in certain areas.

              When it should be done, it should be done in the outside.
              When it must be done, it must be done in the inside.

              Cheers,
              Adolfo
            • Re:Other things... (Score:3, Informative)

              by KiloByte (825081)
              Yes, UNIX timestamps do nothing before 1970, etc, etc

              Incorrect. time_t is always signed, and thus it can represent any time from 1901 to 2038 on 32bit systems, and two thousand times the age of the Universe on 64bits.
              • Re:Other things... (Score:3, Informative)

                by Kjella (173770)
                ncorrect. time_t is always signed

                Unfortunately. that depends on where you look. Let me point you do the latest QDateTime [trolltech.com] class in qt. The relevant bits:

                void setTime_t ( uint seconds )
                uint toTime_t () const

                Now this may be due to limitations on other platforms, but in any case you can't assume that everyone using "time_t", or that think they do, can handle signed integers.
            • by WebCowboy (196209) on Wednesday March 15, 2006 @03:59AM (#14922523)
              My point is that the tool is not always the problem. Now if C++'s integer arithmetic had an issue, that is another story, but the programmer simply was not good.

              No, the tool IS part of the problem in such cases. If the programmer was not that good at C then C was the wrong tool and thus part of the problem. The programmer should've taken the time to study up on C, or picked a different tool. There are times when the tool is not appropriate for the job--you probably shouldn't use C if you need to do heavy text processing and need to get the job done fast (use Perl instead), or if you are less experienced and want a language that supports sound object-oriented programming maybe try Python, etc.

              MySQL was not designed as a robust relational database, and its creators didn't seem to be intent on making it so, or else they'd have designed it differently. It was designed as a very quick and quite dirty SQL frontend/ISAM backend system to support small, informal databases (or so it seems): Basically, its heritage is to be like the old Ashton-Tate dBase but using SQL to query the tables. Since then it has lost that focus and now we have large websites storing millions of records in mySQL.

              MySQL is a great tool if used as intended, however it definitely IS a problem if your accounting system uses it for example. People started doing crap like that and complained about mySQL's lack of features, thus we have things tacked on like innoDB tables and such to add this robustness.

              PostgreSQL was not always as super-robust as it is now, and in its present form its source code is probably almost unrecognisable from 10 years ago, however its architecture was more sound and thought out from the start, as its heritage was as an academic project. Its challenge was not to add features as was the case with mySQL--PgSQL was designed for extensibility. PostgreSQL had to catch up in performance and stability, which it has done in spades.

              Personally, I always use UNIX timestamps (seconds since 1970). They can be directly added, sorted, and converted into any timezone, and its very portable. But thats just me. (Yes, UNIX timestamps do nothing before 1970, etc, etc).

              It seems somehow wrong that your business logic has to perform low-level validation of basic datatypes, and it is cumbersome and error-prone to deal with unrecognisable representations. Only the geekiest of geeks could tell me whether 1984293617 falls on a Thursday without runing it through some kind of conversion program (simple as that may be for a geek). What about people who point-and-click their way through some report designer--they're gonna have to deal with some giant integer in a column entitled "something-date". The other problem is that it is not very precise for some applications that need sub-second timestamp values.

              Personally, I like PostgreSQL because it accepts ISO standard formats, you don't need to do anything to convert timezones--you simply specify the time zone when you insert or query and it issmart enough to figure it out when you query fordatain Eastern time zone and it was inserted in Pacific timezone. Furthermore, it knows Feb 30 isn't valid, and knows when leap years occur, and can format the date in many different ways with simple built-in functions, can be accurate to the millisecond and won't crash and burn in 2038.

              FYI, I believe the "seconds since UNIX epoch" representation of date/time values is a SIGNED integer, so they are in fact good for earlier dates than 1970 (they are good to some time in late 1901 in fact). That is still a pretty limited range and why early systems didn't use that representation inmany cases (couldn't store birthdates for a lot of people who were still alive in the early 1970s becasue they were born before 1901). It is still a problem in some applications ad that is why 32-bit "UNIX-style" time is discouraged.

              I think it's a shame that people resort to such kludges without adequately lookig for more appropriate alternatives...but that's just me ;-)
        • Re:Other things... (Score:4, Informative)

          by consumer (9588) on Wednesday March 15, 2006 @01:22AM (#14922079)
          Strict type checking and triggers are both in MySQL 5, which has been out for a while now. You need to update your complaints.
          • Re:Other things... (Score:5, Informative)

            by jadavis (473492) on Wednesday March 15, 2006 @01:37AM (#14922127)
            MySQL's arguments, like it's features, always seem to be mutually exclusive.

            MySQL's benefits:
            * More Applications
            * Has strict mode if you need it
            * Easier to use by default
            * Speed
            * ACID

            The problems are:
            * Strict mode is not enabled by default
            * If strict mode is easier because of all the benefits of data consistency, then MySQL is not easy by default
            * PostgreSQL has more applications than does "MySQL Strict Mode".
            * ACID is only on the InnoDB table type, and the highest basic data access speed is on the MyISAM table type

            The list goes on. You can argue any one point and say it works just fine, and that you don't care about the other ones.

            But PostgreSQL is a whole solution. When they say you have ACID compliance, it doesn't matter what tables you operate on. When they have a reasonably consistent SQL dialect, it can't be configured to be drastically different on a whim, making half the applications (or more) not even work. In short, the features in PostgreSQL don't have long lists of dislaimers and incompatibilities with other features. They just work as advertised.
        • Reason number 6 (Score:5, Insightful)

          by porkThreeWays (895269) on Wednesday March 15, 2006 @01:57AM (#14922192)
          Reason number 6 is the damnned Postgres zealots that feel the need to bash everyone else's database rather than promote their own. I use MySQL and Postgres on a regular basis. I'm proficient in both. And to the dismay of Postgres users everywhere, there are times which *gasp* MySQL is better suited. "Oh, you are probably a lame programmer and use it for trivial web stuff". Not true! I look at a project and each databases strenths. It has nothing to do with the seriousness of an application. When I was writing VoIP billing software, we'd sometimes see 4-5 million CDR's (call detail records) in a single day. Our first iteration actually used Postgres and choked on that many records. We had to make some compromises with MySQL. We had an additional field for Unix epoch time because of MySQL's lacking (at the time) date and time math. There was a tradeoff. It was deemed that having billing invoices generate in 5 seconds (as opposed to 5 minutes) was more important than programmer time. Welcome to the real world. Another project I had was for writing worker punchcard system. Six months of records only topped out at 50,000 records and we decided Postgres' procedural languages would be a great help to us. Lose the zealots and attitude and maybe you'll have a greater user base.
          • Re:Reason number 6 (Score:5, Informative)

            by jadavis (473492) on Wednesday March 15, 2006 @03:56AM (#14922512)
            My reply was apt. The parent said that there was little reason to switch, I gave some reasons. I stated a fact (that MySQL thinks Feb 31st is a date), which is not bashing. It looks like bashing because it makes MySQL look bad.

            I don't have a problem with other databases. The only database that, to me, stands out as particularly bad is MySQL. That's because their marketing deceives many people.

            Someone may see:
            1. "MySQL supports strict SQL compliance mode"
            2. "MySQL is easy to use from the default install"
            3. "MySQL is screaming fast"
            4. "MySQL has transactions"
            5. "MySQL has more applications written for it than PostgreSQL"

            But...
            #1 conflicts with #2 and #5 because strict is off by default, and there are fewer "MySQL Strict Mode" apps than PostgreSQL apps.
            #2 conflicts with #4 because the default install and CREATE TABLE create MyISAM tables which do not support transactions.
            #3 conflicts with #4 because the "screaming fast" reputation is from MyISAM tables. InnoDB is somewhat similar in performance to PostgreSQL.

            Everything about MySQL pigeonholes you into a subset of the features that MySQL AB advertises, and then makes it as difficult as possible to roam between those features. In MySQL, if you need to change the type of a table, for instance if you want transactions, you can't do that without disrupting running applications. You need to pause and resume all the applications accessing that table.

            Compare to PostgreSQL, if you need to, for example, change the disk that a table is stored on (of course PostgreSQL doesn't have different table types), you can make all the necessary DDL modifications in a transaction-safe way, and the application will never know the difference.

            I know MySQL has uses. I use it (sparingly). Slashdot uses it, for good reasons I'm sure. But "has it's uses" does not mean "immune from criticism".
          • Re:Reason number 6 (Score:5, Interesting)

            by dj-nix (101489) on Wednesday March 15, 2006 @04:28AM (#14922600) Homepage
            Well, thats funny, because I also have had to write VoIP billing software, and am currently writing IP traffic rating and billing software. When I first started this type of business 5 years ago it was with MySQL, but I was frequently both crashing MySQL and getting junk data in my tables (The biggest problem being invalid dates!) When I started searching for a better option I tried a number of databases including FireBird and Postgresql but settled on Postgresql for 4 major reasons. 1) It has absolutely brilliant Date and Time handling, better even than Oracle. 2) It has native INET support which allows easy manipulation, sorting and searching of IP addresses. 3) It has SUB SELECT support which allowed me to reduce my application code a lot, by making the DB do the work (Always a good tradeoff in my opinion) 4) It has VIEW support which allowed me to generate some "simple" views of the data including some summaries which allowed the management to play to their hearts content with MS Access (As a frontend to PG) without having to understand the "real" data layout.
            Of course since then I have discovered many more things to love about Postgresql, including triggers and stored procedures etc (To be fair, MySQL has some of these features now, but did not at that time)
            Just to be clear my first Postgresql app handled ~5 million VoIP records per day on a single CPU, single disk desktop class machine and the only time I have EVER had Postgresql crash was due to a bad ram chip in server! Conversely, I can't count the number of time I and my customers have lost data with MySQL.
      • Re:Other things... (Score:3, Interesting)

        by antarctican (301636)
        Indeed. And once most people are familure with MySQL and the various tools and language support, there tends to be little reason to switch. PostgreSQL is a better database product, but many (all?) of the features that it's cheering section continue to tell us all about whenever the issue comes up, are simply not ones that the majority of MySQL users want or need. Maybe PostgreSQL fans should target Oracle usres.

        Exactly. I know PostgreSQL is a better database engine, but I know mysql, I can't be bothered to
        • Re:Other things... (Score:3, Informative)

          by dodobh (65811)
          You _can_ do the same things from the psql prompt. The system executables just make life easier.
        • What an attitude (Score:5, Insightful)

          by WebCowboy (196209) on Wednesday March 15, 2006 @04:17AM (#14922569)
          I can't be bothered to learn something new when it seems everything supports MySQL.

          I'm glad you don't work for me with that attitude. I'd rather work with someone who is interested in learning new things and will bring some creativity to the job. People of your mentality have to be careful they don't fall into the "false laziness" trap--using some tool or technique or techology because you are too lazy to learn something new, only to end up doing load of extra work to avoid the shortcomings of your inappropriate design choices. The result is scads of legacy code at higher layers of an application to handle things like datatype verification, basic referential integrity and so on.

          All the various different executables to do different tasks rather then one shell like MySQL, a permission system which seemed from my limited usage more perverse then MySQL's

          I've never found it to be a major struggle to use PostgreSQL, though being a more full-featured database it will naturally be a bit more complex to manage.
          I'm puzzled about the "all the various executables" part too, since many of them were invocable from the psql shell anyways. Also, it sounds like you've not lookded at PostgreSQL for awhile because its permissions system has undergone a lot of work--certainly it can be complex but it is very flexible and powerful, and honestly it gets rid of most excuses you had to execute all your database operations under the database superuser (or some other single user account) in your backend code.

          I have better things to do with my time, like write cool code that uses MySQL.

          You might want to examine how you used your time...if you had spent a few hours or a couple days learning something new for a change (like PostgreSQL) then it might've saved weeks or hours of frustration trying to use mySQL for too-complex tasks.

          MySQL might have grownup a lot in recent years, but at its heart it was meant for much more modest tasks, like storing guestbook entries, record collections, as a temporary datastore/embedded database, high-performance querying of relatively static ad/or non-critical data and so on.
          • Re:What an attitude (Score:3, Interesting)

            by koekepeer (197127)
            > > I can't be bothered to learn something new when it seems everything
            > > supports MySQL.
            >
            > I'm glad you don't work for me with that attitude. I'd rather work
            > with someone who is interested in learning new things and will bring
            > some creativity to the job. People of your mentality have to be careful
            > they don't fall into the "false laziness" trap--using some tool or
            > technique or techology because you are too lazy to learn something new,
            > only to end up doing load of extra
      • Re:Other things... (Score:5, Insightful)

        by jbolden (176878) on Wednesday March 15, 2006 @12:39AM (#14921914) Homepage
        I agree with you 100% (and I'm an Oracle guy). Where I think the free databases are:

        Postgres -- getting closer to the kinds of features Oracle users want. Probably about at 8i level now. OTOH speed is nowhere near Oracle

        MySQL -- Roughly the same speed as Oracle. Doesn't scale. Features ain't even close (though 5 is miles ahead of 3, another 10 years and...)

        The problem for Oracle corporation is that 95% of Oracle users don't need the features of Oracle and thus MySQL is a good replacement for them.

        • Re:Other things... (Score:5, Insightful)

          by jadavis (473492) on Wednesday March 15, 2006 @01:25AM (#14922087)
          I would be interested to see some benchmarks to back that up. PostgreSQL has a lot of features that can be used to improve the speed of a query by orders of magnitude.

          What if you have a table and you need a functional index on a user defined function? MySQL can't even do that, so it will be forced to scan the whole table. PostgreSQL makes it trivial.

          PostgreSQL can also combine indexes into in-memory bitmaps before looking in the table. That means you don't have to make a multi-column index for every combination of attributes you select. This is done automatically by the planner.

          When you actually make use of some of the "features that nobody needs" in PostgreSQL, you can see huge performance gains. I'm not sure how it stacks up against Oracle, because they don't let their users publish results.

          But yeah, you're right. If you just port some MySQL code to PostgreSQL, the PostgreSQL code will likely not perform as well (unless there are joins where the planner can use some of the features like the bitmap index).
          • Re:Other things... (Score:3, Interesting)

            by jbolden (176878)
            What if you have a table and you need a functional index on a user defined function? MySQL can't even do that, so it will be forced to scan the whole table. PostgreSQL makes it trivial.

            You are going to laugh but since MySQL basically uses a 1 application model you just de-normalize and have the functional field inside the table itself.

            As for benchmarks there are plenty of benchmarks of Oracle vs. MySQL (a tie to slightly in MySQL's favor on what MySQL does well using cheap hardware. Anything else Oracle
            • Re:Other things... (Score:5, Informative)

              by Decibel (5099) on Wednesday March 15, 2006 @04:51AM (#14922651) Journal
              There are plenty on benchmarks of MySQL vs. Postgres. The Postgres people seem to dispute these but they show MySQL killing Postgres.

              Every single MySQL/PostgreSQL benchmark I've seen has either been absurdly trivial or benchmarked with MyISAM which is an apples to gorillas comparison. And they're all old benchmarks as well. Unlike MySQL's apparent philosophy of "1) Do the minimum to be able to claim we have feature XYZ 2) Make it fast 3) Maybe think about making sure it works sanely", the PostgreSQL community's top-most concern is data quality; performance is always seconday to that. Because of that there had been a lot of room for improvement through the 7.3/7.4 timeframe.

              That's no longer the case. People commonly see 30%+ speed improvements from 7.4 to 8.0, and 2x that from 7.4 to 8.1. And more improvements are on the way. 8.2 is looking to have on-disk sorts that are 4x faster than today, as an example.
  • by tcopeland (32225) * <tom&thomasleecopeland,com> on Tuesday March 14, 2006 @11:23PM (#14921536) Homepage
    ...coauthored an excellent book on PostgreSQL [amazon.com] that was just published by Apress. The title makes it sound like it'd be a bit light, but it takes you all the way up to writing stored procedures, writing C programs that hit the database, using all the utilities, and so forth. I'm using PostgreSQL as a Jabber backend [blogs.com] and the book has already proved useful.

    Too bad they didn't talk about hitting PostgreSQL from Ruby... but since most folks are using ActiveRecord to do that, it's probably not a big deal. And if you use the Ruby/C client [blogs.com], it's quite snappy.
       
  • The name (Score:5, Interesting)

    by smitty_one_each (243267) * on Tuesday March 14, 2006 @11:26PM (#14921544) Homepage Journal
    "Postgre" is three times as long as "My".

    Then again, the P in LAMP has always been about the scripting language, not the database.

    MySQL and PHP have been quite the dynamic duo of the internet.

    That, and PostgreSQL took longer to have a native Lose32 port.

    The fact that you can bring Python right into PostgreSQL for good stored procedure justice seems to go unnoticed.
  • Web developers... (Score:5, Interesting)

    by schon (31600) on Tuesday March 14, 2006 @11:27PM (#14921551)
    I think first and foremost is that is web developers who don't understand SQL, and so go about happily re-inventing its functionality in their web apps.

    99% of the problems that web developers face have already been solved for them, but they think that SQL is just a data dump, and thus see no reason to use Postgres, because they think that MySQL does everything they need. In reality, their apps would be faster to write and easier to maintain if they used SQL features.

    It's kind of like perl-syndrome, but on a larger scale.
  • Nobody's heard of it (Score:5, Interesting)

    by Dlugar (124619) on Tuesday March 14, 2006 @11:29PM (#14921558) Homepage
    The biggest reason I've found personally why people don't use postgres is because they've never heard of it. Everybody and their dog has heard of mysql, but I've never found somebody who knows about postgres who isn't actually using it. mysql, for whatever reason, just has better marketing.

    Why that is I'm not entirely sure, since ever since I discovered postgres, mysql has been relegated to the role of "use-only-when-a-stupid-web-app-can't-use-anything -else". If I want a toy database, I'll use sqlite. If I want a real database, I'll use postgres. There really isn't much room in between the two.

    Dlugar
    • I've never found somebody who knows about postgres who isn't actually using it.

      Of course! PostgreSQL is so good that when people learn about it they switch to it. Hence anybody who knows about PostgreSQL uses it.

      Ever since I discovered postgres, mysql has been relegated to...

      Precisely!

  • by dskoll (99328) on Tuesday March 14, 2006 @11:29PM (#14921563)

    I don't hear those reasons when people dismiss PostgreSQL. The ones I hear are:

    • VACUUM is a pain. It's true that VACUUM is annoying, but later releases (especially 8.0 and 8.1) make VACUUM much more tolerable; we have customers whose databases are busy 24/7, and although the load does go up during a VACUUM, the database is still perfectly usable.
    • PostgreSQL is slow. That was true, but the 8.x series has improved performance dramatically.
    • PostgreSQL is hard to install and administer. Really, I think this is a matter of taste. If you are used to MySQL, then yes, there is a learning curve. OTOH, I'm used to PostgreSQL and find myself having to learn MySQL, and MySQL feels just as weird and unintuitive to me as PostgreSQL might to a long-time PostgreSQL user.
    • OTOH, I'm used to PostgreSQL and find myself having to learn MySQL, and MySQL feels just as weird and unintuitive to me as PostgreSQL might to a long-time PostgreSQL user.
      So, what you're saying is... PostgreSQL will be strange and unintuitive, no matter what database you prefer and use? :P
    • VACUUM is a pain.

      Use autovacuum. The current version has autovacuum built into the backend. How much easier can it get? And it shouldn't interfere to much with concurrent connections.

      PostgreSQL is slow.

      It gets this reputation if you run a MySQL app on top of PostgreSQL because MySQL does some types of things faster. However, I think you'll find in many cases the application will have superior performance to the MySQL version if you write PostgreSQL specific code in the application's data access layer.
    • A few more reasons (Score:5, Insightful)

      by jdoeii (468503) on Wednesday March 15, 2006 @02:42AM (#14922305) Homepage
      VACUUM is a pain. It's true that VACUUM is annoying, but later releases (especially 8.0 and 8.1) make VACUUM much more tolerable;

      Vacuum kills performance. Some uses maybe OK with loosing 50% or more while VACUUM runs. In some uses it's unacceptable. In our case (a lot of inserts with majority of selects going for the newly inserted records) performance degrades within 6-8 hours after running VACUUM & friends. VACUUM takes ~20 minutes to complete which is completely unacceptable during the day and we can't delay it till night.

      No, AUTOVACUUM is not an answer because it kicks in unexpectedly and makes random queries run unexpectedly slow at unexpected times. Usual VACUUM makes all queries run slow at predetermined time. Not a very appealing choice.

      More reasons:
      • No memory management. For example, here is 1GB database on a dedicated host with 2GB of RAM. PG should suck the while DB into RAM and run selects from there, right? Wrong. PG is extremely frugal about memory management. It caches the last few results, but otherwise goes to disk for data even if there is anough RAM to cache the whole DB. The PG developers keep saying that it's the job for the OS. Now, which OS should we use then? FreeBSD, Linux, Windows? Which one?
      • Forever broken COUNT(). Although MIN & MAX were fixed in the latest release, COUNT() is still broken and there is no fixing in sight. Yes, I beieve 10 seconds execution time for count() on a table with just a few million records qualifies it as a broken feature.
      • Of course, the query optimizer/planner can be improved, but that's understandable and can be applied to pretty much any DBMS
  • by malraid (592373) on Tuesday March 14, 2006 @11:29PM (#14921564)
    Their database (MySQL, Access, Oracle, whatever) is working for them good enough to justify switching. Me? I'm using PostgreSQL, and I won't switch, even though Oracle now has a free version. Too much work to fix something that's not broken. And while I might never be able to use MySQL in my main project because it lacks some features I really need, it's good enough for lots of people.
  • rep-lih-kay-shun (Score:4, Interesting)

    by buddha42 (539539) on Tuesday March 14, 2006 @11:30PM (#14921565)
    None of those five had anything to do with why we can't use it. Postgres's replication options are niche afterthought hacks. This immediatly makes it an unacceptable choice for anyone who's reliability or performance needs exceed that of one server. Which is pretty much any system where the cost of downtime is non-trivial.
  • #1 Reason (Score:5, Insightful)

    by kingmundi (54911) on Tuesday March 14, 2006 @11:34PM (#14921593)
    It has to do with mindshare and previous history. Way back in the day... 1997, postgres was difficult to setup for some people. It was not the default choice included in many setups at ISPs. If you wanted to have an interactive web application at an ISP, on a unix machine, the most common option was MySQL. (On a windows machine it would be an ODBC connection to an access database, or a MS SQL server) Once something has achieved a significant mindshare and some momentum it is difficult to overcome. (But not impossible, especially if you do a better job, just takes time)
  • Or this? (Score:4, Interesting)

    by Ex Machina (10710) <jonathan.william ... m ['ail' in gap]> on Tuesday March 14, 2006 @11:34PM (#14921595) Homepage
    Speed isn't everything but some of these are insane [sqlite.org].
    • Re:Or this? (Score:5, Insightful)

      by rtaylor (70602) on Tuesday March 14, 2006 @11:50PM (#14921684) Homepage
      Do you really only have one user using the database at any given time? If you do only have one user, speed probably doesn't matter at all.

      Benchmarks like that should be run with a couple of hundred active users all doing different things (mix of updates, insert, deletes, and selects) -- a real world use-case.

      You will quickly find that scores change.

      We had a MySQL versus PostgreSQL battle once. The MySQL people put together a benchmark showing MySQL was nearly 10 times faster. The benchmark was a single user going through the steps.

      We then took the exact same thing and put Apache in front and benchmarked with 5 active users -- now they were about even. At 10 users PostgreSQL was about 5x faster. At 100 users MySQL was unable to finish the test. PostgreSQL was serving each of the 100 users at a rate comparable to how it dealt with 10 active users.

      Benchmarks for benchmark sake is useless. Benchmarks that model your actual use case are quite valuable.
      • Re:Or this? (Score:3, Informative)

        by consumer (9588)
        The older table type in MySQL, MyISAM, doesn't handle concurrency well. The InnoDB table type uses the same locking approach as PostgreSQL and Oracle, and should stand up to multiple users much better.
  • by Trogre (513942) on Tuesday March 14, 2006 @11:35PM (#14921599) Homepage
    Why do people dismiss PostgreSQL

    It's because LAMP sounds so much cooler than LAPP!

  • Personal .02 (Score:4, Interesting)

    by cliveholloway (132299) on Tuesday March 14, 2006 @11:37PM (#14921608) Homepage Journal
    At OSCON, the Postgres people had postcards on their table of whatever their mascot is (I forget) roasting a dolphin on a spit over a fire.

    Funny yes, but not something that inspires one to take them seriously.

    Ironically, they have a better product on many levels, but that kind of zealotry just plain puts me off.

  • Fulltext Indexes (Score:5, Insightful)

    by inio (26835) on Tuesday March 14, 2006 @11:37PM (#14921609) Homepage
    I have pretty simple requirements for a database, I don't need triggers, stored procedures, or any of that stuff. What I need for web applications is a database that I can efficiently search, and that means fulltext indexes. Sure, there's plugins for Postgres that add fulltext indexes, but they require ungodly complex setup and tuning. With MySQL it's two keywords.
    • Re:Fulltext Indexes (Score:4, Informative)

      by Ragica (552891) on Wednesday March 15, 2006 @04:27AM (#14922593) Homepage
      Yes, like most things MySQL, it's simple to get going and hooked on, but half assed, and will bite your ass later if you ever grow beyond a certain point... or in certain directions.

      But of course anyone who is is willing to tolerate MyISAM tables (which mysql's full text indexes still seem to require) already has pretty low standards for their data. (I don't mean "low standards" in a derogatory way.)

      As a programmer of a search engine built on postgresql's tsearch2 I can confirm that it is a pain in the ass in a few ways. Installation isn't one of them. And in fact setup, while certainly more involved than MySQL, isn't very difficult either... if you can be satisfied with the defaults (just run the bundled sql setup script).

      The main problem with the defaults for me is the crude "snowball stemmer" (does MySQL have any stemming support? I did a quick google search but couldn't seem to find any info... though i note some plugins that seem to offer it). Once you get tsearch2's dictionary based stemmer working, things become much more wonderful very quickly.

      On the other hand for anyone who cares about full text search tsearch2, in it's complex design, offers a vast amount of configurability and power. It's indexes are pretty fast. There are multiple ranking algorithms, a "headline" function for pulling highlighted extracts from found text, (limited) field weighting, replaceable tokenizer, multiple languages and encodings, and on and on.

      Unfortunately I don't think it comes close to something like lucene. But that's another kettle of fish.

      Regarding MySQL's full-text search I came across this nice quote (from Kate of Wikipedia):

      We already support MySQL's fulltext search. Its uselessness is mainly what inspired me to write the Lucene support :)

      Of course the parent poster says up front that they have "pretty simple requirements" so all of my comments above probably make no impression at all. But anyhow, just something to think about.

  • BullShit (Score:5, Funny)

    by slashpot (11017) on Tuesday March 14, 2006 @11:42PM (#14921629) Homepage
    #1 because we're lazy ass sys admins who learned mysql first and don't want to bother learning another software package that does more or less the same shit . sad . true .
  • by Martin Foster (4949) on Tuesday March 14, 2006 @11:44PM (#14921640) Homepage
    PostgreSQL is not necessarily the easiest beast in the world to get going. A few years back, I converted a chat/gallery portal system Ethereal Realms (http://www.erealms.org/ [erealms.org] from MySQL to PostgreSQL, since at the time it was felt that features like proper referential integrity and stored procedures would really pay off.

    The code was shortened considerably, was more stable overall and the OpenBSD port compiles properly without threading issues. However, despite all of those advantages and the database server being on a bigger server with more memory performance suffered considerably.

    Want a good starting place in settings? The default documentation does little if anything to really help you on the matter, its like trying to learn the English language solely through the use of a dictionary.

    There are tutorials available, some out of date and while Usenets can certainly help, you'll get wildly varying answers because some of the configuration options are more black magic then science. Rather makes it hard to get started when you don't know exactly where to start or how increasing a value will really affect performance as a whole. You are expected to load test the database before implementation which is not always possible for small hobby sites, and it can test patience.

    With MySQL you had a few configuration files designed for use in various environments and it would show you how certain settings had changed. This is not the case with PostgreSQL in fact 32 connections is the default which is painfully inadequate for most peoples needs when dealing with a site. I'd personally love to see an application that detected your memory and other settings and came out with sane settings, at least with such an option you'd have a place to start.

    Queries were slow, but then that was supposed to be MySQL's strength. Solution? Run explain/analyze on everything and tweak the hell out of every single query being generated. If you don't necessarily understand how the query is analyzed and run by PostgreSQL then there must be something wrong with you!

    Vacuum? That concept alone can throw people in for a loop, especially when designing a system which is meant to be run by people with no technical experience. So you have to code in a serious amount of intelligence into the application or rely on Auto-Vacuum (not available at the time) which can slow performance down even more.

    Because of vacuum, I had to design a process for the site to lock out all users. This had never been required under MySQL and took a while for the users to get used to. In certain cases, if the lock-out failed, the vacuum would cause permanent locks in tables which would quickly pile up scripts on the webserver side leading to extreme high loads or just crashing the machine.

    PostgreSQL has a LOT of features and a lot to offer in general. However, there is a major learning curve required to get it going right. I've had other sites implement the code and whenever they hit the version which required PostgreSQL most gave up on the idea of migrating or complained endlessly on how things seemed sluggish. That is NOT a major selling point when trying to get the unwashed masses to adopt your product.

    • I'd personally love to see an application that detected your memory and other settings and came out with sane settings, at least with such an option you'd have a place to start.
      There is this [postgresql.org] old (and seemingly abandoned) project (pg_autotune). I haven't got around to trying it for the last 3 years, but have always intended to...
  • A huge omission (Score:4, Informative)

    by PornMaster (749461) on Tuesday March 14, 2006 @11:45PM (#14921644) Homepage
    If you're doing something on Solaris 10 that doesn't need you to pay out the ass for Oracle, you can get PostgreSQL supported by Sun.

    http://news.com.com/Sun+backs+open-source+database +PostgreSQL/2100-1014_3-5958850.html [com.com]
  • No newbie guides (Score:5, Interesting)

    by kyndig (579355) on Tuesday March 14, 2006 @11:48PM (#14921672) Homepage
    When I started programming a website, I knew I needed a database. I also knew absolutely nothing about php, sql, or even what they stood for. I was using a Perl based hacked link farm that used a flat-text database storage. Someone then pointed me to a php link farm that used MySQL. The installation text that came with the app was so easy to follow for a newbie, I had the link farm up and running in no time. I went to Books-A-Million a few weeks later, and found many books on PHP, MySQL, php/mysql - and nothing on PostgreSQL. When I finally did read up on RDBMS, found out that PostgreSQL did some functionality that MySQL didn't (at the time); I already had most of my site designed in php/mysql. I looked more into sub-queries in PostgreSQL, but the community structure was so scattered and non-newbie friendly, I decided to stick it out with MySQL (and havn't regretted it once). So my reasons for preference have nothing to do with wanting a windows version, different language, or other such assumption. Instead, my reasons are:
          * as everyone says, the name is catchy: MySQL
          * when I first was introduced to it, and to this day, Michael 'Monty' Widenius takes a personal interest in his work, and is a real down to earth guy ( had the pleasure of emailing him once) [you can probably still see him posting on the mysql dev lists these days..though I havn't followed it in a couple of years]
          * Extensive script language support for web development
          * Books for newbs and professionals (many books)
          * I like their website more..always have

    My shallow reasons..
    • No newbie guides (Score:4, Insightful)

      by Saeed al-Sahaf (665390) on Wednesday March 15, 2006 @12:38AM (#14921913) Homepage
      I went to Books-A-Million a few weeks later, and found many books on PHP, MySQL, php/mysql - and nothing on PostgreSQL. ... I looked more into sub-queries in PostgreSQL, but the community structure was so scattered and non-newbie friendly

      Two of PostgreSQL's biggest problems: Very little documentation that mere mortals can read (if they can even find it), and a rude, elitist cheering squad. The product my be the greatest thing to hit Open Source since RMS, but most people who need a database (usually for web dev, but yes, often for "real" applications as well) will never find out about all of PostgreSQL's golden features.

  • by nko321 (788903) on Tuesday March 14, 2006 @11:52PM (#14921691) Homepage
    The reasons listed in TFA are nowhere near why I don't use it (granted, I've only used databases as toys thusfar).

    A few years ago, I decided to learn a DBMS and teach myself SQL. I tried Access because it's "user friendly." Call me crazy, but I felt it was anything but. So I tried Postgres because everyone spoke so highly of it (and I'm very comfy with the command line). I read a lot of documentation and did a lot of things that felt like "progress" before I gave up.

    I picked up MySQL next. It had some quirks, sure, but it was maybe an hour before I was comfortable enough with the DBMS that it didn't stand between me and learning SQL.

    I picked up Postgres again last year and got much further along with it. I actually made a database, and it had tables and everything. I gave up because everything just "felt" more complicated than in MySQL.

    I really want to learn Postgres. I do. I'm convinced it's more powerful and flexible. I just don't have the time, patience, or need.

    Both MySQL and Postgres have their quirks that make it so you can't just jump in and start playing with SQL, and that sets the bar higher than it needs to be. Sure, every product will have some such complexity, but the lower the bar, the wider the userbase.
  • by drgroove (631550) on Wednesday March 15, 2006 @12:02AM (#14921735)
    ...because I don't know how to pronounce it.

    Is it "Post Grace"? "Post Grey"? "Poss Grey"? "Poss Gres"? "Progress"? "Platypus"? "Post Raisin Bran"?

    Whatever it is, it sounds vaguely French, which is just suspect to begin with. And I'm not dredging up the whole Iraq/UN thing either, although if I have to invoke Freedom Fries to make a point, I've got the mayonnaise ready.

    Give me a RDBMS that I can pronounce, and I'll use you in my software.
    MySQL. Easy. "My SQL". Doesn't get much easier than that, plus it sounds sorta friendly.
    MS SQL - same thing, slightly different spelling. Maybe not as friendly, but you can put it in a Powerpoint to your boss and not sound like an idiot.
    Oracle. Now you're talking. Even has a bit of mistique to it, a bit of enigma.
    DB2. Not as sexy, but still undeniably pronouceable.
    Sybase. Sock it to me.

    What PostgreSQL - however the hell you say that - really needs is a new name. Forget features, forget marketing, forget RDBMS death match performance comparisons. Nobody cares. MySQL lacked tons of features for years, and we all used it then and continue to use it now. Why? You can pronounce it. Simple.

    • by kestasjk (933987) on Wednesday March 15, 2006 @02:42AM (#14922304) Homepage
      PostgreSQL/Postgres Post-gres-Q-L The es at the end of gres has to sound like the 'S' in 'S-Q-L', so it's an obvious pronunciation. However MySQL My-S-Q-L or My-See-Quel Apparently it's My-S-Q-L, but there's no way of knowing that by reading the text alone. What other reasons do you have? A dislike for elephants?
  • by hogghogg (791053) on Wednesday March 15, 2006 @12:03AM (#14921745) Homepage Journal

    FWIW, I have had very good experiences running postgres in astronomy applications, including for of order millions of galaxies with of order hundreds of attributes in the Sloan Digital Sky Survey [sdss.org]. For scientific applications, open-source is a must, because (a) you have to be sure that the db is doing what you think it is, (b) you have to be able to rely on support or self-maintainance into the asymptotic future, and (c) (usually) you end up having to make small customizations.

    Point (b) is especially big: in the Sloan Survey early days we had a proprietary database with our only copy of some of our data; when the company went belly-up (I think is was Objectivity), our data was effectively "encrypted" in whatever proprietary internal format was used by Objectivity and we had no way to reverse-engineer it, and no-one to call.

    On point (c), try calling Oracle or Microsoft and asking for customizations that astronomers want. Evidently they don't consider us an important part of their market!?

  • by mpn14tech (716482) on Wednesday March 15, 2006 @12:14AM (#14921803)
    Although where I work we would like to use postgresql, we do not because it does not support case insensitive queries like mysql, sql server and sybase.
    • by chundo (587998) <jeremy.jongsma@org> on Wednesday March 15, 2006 @12:32AM (#14921890)
      Postgres can create indexes on functions. So if you need case-insensitive queries, you can create an index like the following on your table:

      CREATE INDEX my_index ON my_table(LOWER(column_name));

      Then you can use something like the following query:

      SELECT * from my_table WHERE LOWER(column_name) = LOWER('Search String');

      This gives you case-insensitive searching with no performance penalty. A little more setup involved, but the same functionality as the other DBMS's you mention.
    • Just create a functional index on lower(column) and search on lower(column). There are likely other solutions to this problem (such as ILIKE).
  • Why I chose MySQL (Score:5, Insightful)

    by Reality Master 101 (179095) <.RealityMaster101. .at. .gmail.com.> on Wednesday March 15, 2006 @12:16AM (#14921813) Homepage Journal
    First, let me say that one of my "real" sites uses PostgreSQL, has used it for about six years, and I'm very happy with it. It was the right decision.

    Now, about a year ago, I had a client that wanted a web site back-end written. Now, I wasn't sure what the future of that site was going to be, whether I was going to be involved, etc. I also knew that it would be probably be run on inexpensive shared hosting solutions.

    Guess what I chose? MySQL and PHP. The reason was because those are always available. It gives my client the flexibility to move it to any hosting solution. PostgreSQL simply is not everywhere. In my case, I run my own servers and can afford to have to understand it. But my client needs a hosting solution that does all the work for him (including back-ups). There's something to be said for using "the standard".

    And you know what? I originally chose PostgreSQL because it was ACID compliant, but I have to say that MySQL sucks a lot less than it used to. It defaults to tables that support commit/rollback. It supports sub-transactions (which PostgreSQL v7 doesn't support, not sure about 8). It (FINALLY) supports sub-selects. If you're still turning up your nose at MySQL, it really isn't as bad as it used to be.

  • How about... (Score:3, Insightful)

    by JoeCommodore (567479) <larry@portcommodore.com> on Wednesday March 15, 2006 @12:19AM (#14921829) Homepage
    Installation

    Good installation documenation with Postgres is pretty sparse. It's not too complicated but it's not easy to find answers. This mainly includes how to properly setup pg_hba.conf which is vague at best on how to configure.

    It might be better in newer installs but in RHEL3 I was just scraping along.

    Application Support

    As mentioned there are some great apps, but there are just are not many applications supporting Postgres, most web apps are LAMP (with M being very much in represntation). I think it would help Postgre if there is a comprehensive PHP-PGSQLPHP-MYSQL conversion equivelants document/tool to help developers either to transition or at the least open up the cross-platform support for multiple DB engines.

    Documentation

    Recently there have been a growing number of updated books on Postgres including those which work along with PHP, so that situation is improving, the books I had to work with were circa 2000 or earlier before schema support.

    So, yes, I tried it, for a while, almost got there, but I just wasn't achieving as much progress as I had hoped. Maybe later I'll go back when conditions get better.

    Keep up the good work, I'll be watching.
  • Competence required (Score:4, Interesting)

    by linuxwrangler (582055) on Wednesday March 15, 2006 @12:22AM (#14921848)
    One "problem" with PostgreSQL is that it assumes actual competence on the part of the administrator. The default ./configure ; make ; make install is designed to create a system that will actually start up on as many platforms as possible. After that, it is up to the competent administrator to tune it for the specifics of the installation. Using the default PG install in a performance comparison demonstration shows nothing but the incompetence of reviewer.

    Have a 2 CPU AMD64 box and 16 GB RAM and fast SCSI drives as your dedicated DB server? Fine, make your settings appropriate for that. Running on a shared P200 with 128M RAM and a slow IDE drive? Different tuning entirely. I have production systems at both ends of the scale.

    I am extremely happy with PostgreSQL. It's robust as hell - I've had individual PG connections to the DB up for over a year. On rare occasions I've had a machine running PostgreSQL get unceremoniously killed but every single time when the machine has been restarted, PostgreSQL has started up without any problem. This is not always the case [wikinews.org].

  • by sk999 (846068) on Wednesday March 15, 2006 @12:53AM (#14921981)
    Many years ago we looked at Postgres, and the developer at the time said that "he would not trust his payroll to it."

    The database has improved a lot since then, and I currently support two Postgres databases, one on Linux and one on IRIX, both running in mission-critical situations. What that means is that if either one fails, I get phone calls in the middle of the night with complaints. In over 6 years, I have not fielded one phone call attributable to Postgres itself.

    None of the issues raised in the article was even remotely a factor in my choice of Postgres. A big (and ultimately deciding) factor in its favor is that it can be compiled and installed on a broad range of hardware and operating system versions. MySQL fared less well in this regard.

  • by GISGEOLOGYGEEK (708023) on Wednesday March 15, 2006 @03:07AM (#14922368)
    Most people avoid Postgres because they are totally ignorant and are going with the popular flow no matter how ugly it is. They've jumped on the MySQL bandwagon with no regard for what they are missing.

    Heck do you want ignorance? ... I know one dumbass who spent $8000 for SQLServer based on a lie from the Microsoft salesman who told the dumbass that Postgres can not in any way handle Triggers! The fool couldn't be bothered to ask me or even to spend 2 minutes at postgres.org. Then there's other people who think your shop has to have the big name software or else you won't have any credibility with your clients. Hmmm ... have smart clients who get from you a cost effective and powerful product at a good price ... or have stupid clients who's money passes from you to the Database salesmen, leaving less for you. Which do you prefer?

    I haven't seen much about the windows world in this thread ... so here's my 2cents.

    I am not proficient in Linux. It took me two weeks of spare time to get postgres with the PostGIS spatial engine up and running properly. The pathetic typos in the configuration scripts, the dumbass instructions that contradicted the contents of the files they described ... it was a nightmare, no wonder people didnt use it.

    Then, about 1.5 years ago, a Windows installer came out for Postgres and PostGIS and it all changed.

    Literally 5 minutes later I was adding data to my spatial database and learning how to use the powerful spatial query functions.

    Sure MySQL does have some brutally weak spatial abilities, but its a joke compared to what PostGIS can do.

    Suddenly Windows users got to make the equivalent of an ArcSDE backend for their UMN MapServer websites, instead of spending $50,000 on ArcIMS with Oracle / ArcSDE. Heck I can build a few such sites for less than what the software costs to use the ESRI / Oracle crap.

    The moral of my story and main reason for people avoiding the current, powerful, fast, spatially enabled postgresql is that people are stupid. Disagree? ... remember that you are the people.
    • by ensignyu (417022) on Wednesday March 15, 2006 @05:47AM (#14922772)
      A small change:

      "Most people avoid Linux because they are totally ignorant and are going with the popular flow no matter how ugly it is. They've jumped on the Windows bandwagon with no regard for what they are missing."

      I think that you, as someone not proficient in Linux, should at least appreciate that some things are a pain in the ass to learn, even if there are considerable benefits. Don't be so quick to judge people who haven't adopted your favorite database package or OS or seafood dish.

The confusion of a staff member is measured by the length of his memos. -- New York Times, Jan. 20, 1981

Working...