Slashdot Mirror
Oracle and PostgreSQL Debate
Mark Brunelli writes DBAs are talking about the merits of the open source PostgreSQL database management system (DBMS) as compared to Oracle - and their opinions truly run the gamut. DBAs responding to the interview said they liked the low cost and ease of use of the open source database, while others said that Oracle's rich feature cannot be ignored. Still others talked about how well the two systems play together. According to one DBA, a gateway product from Oracle would be a welcome offering."
http://ingres.com/
Agile Artisans
obviously they've never tried to dump and restore a database when upgrading to a new major release. Never goes according to the documentation. thats why I love mysql, just install the new rpms and keep on truckin'.
/etc/passwd for authentication of users/passwords, I hate that it has to use its own internal user/pass database.
I just wish mysql could use
Does the name Pavlov ring a bell?
If they want something that plays nice with Oracle, they should take a look at http://www.enterprisedb.com/ .
One of the goals of the company is aimed specifically at making life easier for Oracle people on PostgreSQL.
Company I work for runs both PostgreSQL and Oracle. Years ago we were a PostgreSQL only shop. Along comes a Sr. Developer who touts Oracle to management, and they listened to him.
Now we have 2 Sr. Oracle DBAs, 1 Jr., and 2 PL/SQL programmers.
Oh yeah, we don't have any PostgreSQL DBAs. But we have just as many PostgreSQL servers.
Now we are moving some of our applications back to PostgreSQL, which of course scares the Oracle DBAs.
Our servers are heavy-hit. Thousands of queries per-second on both systems. PostgreSQL can keep up with Oracle, and Oracle can keep up with PostgreSQL.
One thing I've noticed about the market that is both good and bad for PostgreSQL - You can put out an Ad for an Oracle DBA and get hundreds of responces. Put one up for PostgreSQL and you get almost none. Almost a year we've had an Ad out for a PostgreSQL, there just arn't any.
And I don't think its because there arn't any full-time DBAs. The reality is PostgreSQL just doesn't need the same amount of staff that an equal amount of Oracle databases need. The good side, it just works and requires so little maintenence. The bad side? Its hard to sell to companies when they can't have someone full-time on it.
I'm curious with other companies experiences. How many full-time DBAs do you have for Oracle? How many for PostgreSQL?
Post gre ess que ell
Post gres SQL
Post gres QL
...that ANYONE /needs/ Oracle.
I will accept that someone would need something like Oracle Financials and that would be contingent upon using the Oracle database, but structurally speaking, why is it necessary for anything in particular? I mean, cripes, GOOGLE uses MySql. If THEY don't need Oracle, who the hell does?
I've run into this before trying to sell a TINY Division on using MySQL or PostgreSQL--every single !#!#%ing engineer said the same thing: we don't need _anything_ beyond MySQL, hell PostgreSQL is even overkill, so let's use it. Absolutely not, was management's response no matter how many high-profile case studies we threw at them. It was as if the #1 requirement was "Must cost at least $57,000, but list for $75k, so the purchasing manager can get a nice fat bonus for 'saving' money."
Seriously, I'd like someone to explain what precisely about Oracle could ever be considered absolutely necessary that cannot be found anywhere else aside from organizational bias and insipid politics.
Like any profession, database administration is rife with the mediocre and downright incompetent. For those, Oracle and the like provide an awesome service. A DBMS that works half the time, and the half the time it isn't working, there are documents, online knowledge bases, and expensive tech support personnel who can read to you from their CDROMs.
If you really want to know if PostgreSQL (or MySQL) can handle it, look at the best and brightest tech corps in the world. I'll pick two for you: Google and Yahoo!. They use MySQL extensively. IMO PostgreSQL can do whatever MySQL can (though, honestly, I'm not sure, I've only ever seen MySQL in high volume environments like Digg, where I'm currently working).
If your org *NEEDs* Oracle or Sybase or whatever because MySQL and PostgreSQL aren't supported by some software you bought, I feel sorry for you, and recommend you either accept your company's mediocrity or get out.
If you think MySQL/PostgreSQL just don't have what it takes on a fundamental level, I humbly suggest you rethink your competence in the field.
fifth sigma, inc.
I have become increasingly frustrated with Progress for about 2 versions now. The 4GL is clunky and limited, and the implementation of SQL is poor. Interoperability with free software tools, languages and databases is practically nonexistent, so you get tied into an all-progress solution. That just grinds my gears.
But at least empty string isn't a null. WTF were Oracle thinking?
Anyway, this is so offtopic. Postgres is entirely adequate for anything you would do with Progress, and it's relatively unencumbered with bullshit.
I want to know who has a job where they have so much extra time on their hands that they can debug the source code of their database product.
Nobody except the active contributers to the RDBMS I'm guessing. Certainly not be. But I'll tell you my personal experience with PostgreSQL and how it being open source directly benefited me:
I was doing a project involving PgSQL many years ago (v6.2 I think) to manage a small inventory database. There was a problem that looked like a bug in PgSQL rather than a configuration issue (I think it was causing VACUUM to fail among other things but my memory fails me). What I clearly remember was how I resolved the issue, and it is the first time that the benefits of open source directly affected me and when I becane clearly sold on open source.
I had given up and since there wasn't a company to turn to I looked for contact emails in what passed for the docs at the time (they are MUCH better now) and on the website. I emailed one of the core developers and described my problem. He emailed me back the next day and thanked me for my feedback and said he had a few other reports of problems somewhat similar to mine. He also ATTACHED THE SOURCE CODE OF THE PATCH he had been working on that was not yet in the release on the website! I applied the patch and recompiled and bingo...it was back to normal!
Now I was (still am) far from a guru C programmer but as with a lot of people I can stumble my way around makefiles and GCC and patches and so forth, and I did have time to recompile PgSQL. I can also (at the instruction of one of the developers) to traces and such and send in the results and THEY can do the debugging with my help. If I was using Microsoft SQL Server and had a similar problem I'd be screwed: I'd have to call clueless tech support, or wander around the KB articles and hope to find the solution, and in this case I'd probably find a useledd KB article along the lines of "Microsoft has acknowledged this to be an issue and will provide a solution in the next available hotfix" telling me to do some kludgy, unacceptable workaround in the meantime, which could be days, or weeks...or maybe even never. I certainly would NEVER have the ear of a Microsoft programmer who wrote or reviewed the code as a lowly intern-type doing a small experimental project.
So there you go...I'm (a) not an "elite programmer", (b) never been part of the PostgreSQL team beyond exchanging emails with a team member, and (c) though some may say I am a nerd I moved out of my parents' home when I was 17 and never lived in their basement. Despite that I have indeed directly benefited from source code availability for software that I did not write.
I've been a oracle dba for a long time, and recently turned my back on oracle to seek other career challenges. I think the short explaination for my decision, is that the speed of hardware has grown to overwhelm most any real world performance problem, with just "good practices" as a dba as opposed to having to be some kind of hero dba. So there is no future there as far as $$.
/sec on a few xeon servers facing a few FC disk arrays. PG or MySQL will never do that even on the same hardware, since they don't parallelize and they don't do directIO and asyncIO in a pervasive or big way. This is the classic datawarehouse design and is probably a bastion for oracle (oracle is basically trying to eat terradata from the lower end)
I built some very large, very high thruput databases under difficult conditions (torrid growth at paypal) and I don't think it could have been done with that hardware and even todays mysql or postgres: only oracle had the features then, and it's features then exceed what pg and mysql have *in the category of scalability and serviceability*. This mostly stemmed from the difficulty of doing transaction safe database calls across multiple machines forcing us to scale a single machine for a very long time. And before anyone says pg and mysql have transactions, I"m talking about billions of dollars of transactions, where if you loose or fail to recover even a few you risk goign out of business because customers stop trusting you.
But moores law and whatever law applies to disk densities just crush any classic RDBMS problems. Number of spindles can still be sort of costly, but way cheaper than even 5 years ago. memory and cpu are practically free, making it unecessary and wasteful of time and money to obsess over tuning, inall but the most exterme cases.
If you're writing a custom new application, fuck oracle, except in those cases fall along these few lines:
- you want to do truly massive scans of multi terrabyte tables: Oracle RAC will do 2-4 gigabytes
- you want > 99.9 uptime: You will still need to work 10x harder in the application to get this or better, but you'll also need the serviceability of oracle e.g. index rebuilds corruption fixes without reboot. Also, the visibility and monitoring of oracle is lightyears ahead of mysql and pg.
- you want to build an empire as a middle manager
- you are writing a turnkey application you plan to sell to corporate america or govt.
That's nonsense. It doesn't crash. What it does do is wait for you to give it some more space. As an administrator, that's a fairly easy thing to do. Once you've done that, Oracle continues on its way as if nothing had happened.
I am Oracle DBA (RAC and single instance) and I don't know what kind of screwy setup you have going on there but there is no it should crash if the file system fills up. The worse I have seen is not be able to log into (as anyone other than sys) a database that is in archive logging mode because it can't write anymore archive log files, this is expect behaviour not crashing.
Whem my datafiles out grow their disk I just get a warning similar to "Can't extend tablespace by 8k etc...." it _doesn't_ crash.
It said "windows 98 or better" so I installed Linux
I had the "pleasure" to work on eveolutive maintenance of a large Progress project for 4 years.
Progress, despite its name, is really a collection of relic, non-standard concepts and technologies, with bizzarre and arbitrary ideas like implicit transaction scope, rollback on memory data structures, a 4GL that grown in a sort of Frankestein monster of a language, pathetical error checking, inflexible data model and convoluted syntax to replicate stuff, like cursors, that other DBMS had sported for decades.
Add horrible performance under ODBC/JDBC ("but we have solved that now, and we needed only 3 major revisions of the platform to get it right!"), grudgily, non-integrated support for SQL (SQL-89 to be precise) a bolted-on-the-side OO (released this February, so untested in the field, apart from the obvious fact that they added another cartload of statements to a bloated language) and the fact that anything invented in the last 30 years (from sockets to XML) is either impossible to do or extremely clunky, and you have "Progress".
My opinion is that it survived because it was quite successfully in the 80s, and created a niche industry centered around specific vertical solutions.
Imagine Powerbuilder without the OO or the ability to interface with diverse RDBMS and you will have a vague idea of what Progress is.
Progress - the company - actually controls an umbrella of diverse technologies, some even very interesting like Sonic, but Progress - the product, is something that should have died a long ago, or be revamped instead of adding more and more stuff without ever deprecating language features from 5+ versions ago.
Using Postgres for long term data retention is a bad idea. The database format chances often, and the migration tools are unreliable - pgdump has a nasty tendency to produce dumps that can't be read back in even to the same version, much less next version.
Got me bad when I reinstalled Debian (stable) after a hard drive failure - Postgres had been updated, and it turned out to be impossible to read the database dumps made with the previous version. A pity - Postgres is otherwise pretty good, but such data loss is simply not acceptable.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.