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."
90% of the people who use it don't need it. 100% of that 90% are/have been convinced they need it.
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?
I like how I can call Oracle and get the best developers/DBAs/integrators/troubleshooters to solve my problem, and it requires only money. I like how I can look at the Postgres source code, so I don't have to call anyone to solve my problem - or I can choose who I call.
--
make install -not war
Uhh...is editing a config file really that difficult a process? It's like two lines.
Why does everything have to be all or nothing? There's nothing stopping an Oracle shop from using PostgreSQL here and there. Plus you've got EnterpriseDB, which bolts Oracle compatibility onto PostgreSQL for a little bit of the best of both worlds. Go ahead and pay Oracle for the top end of what their feature set lets you do and use PostgreSQL for the rest.
Breakfast served all day!
To me, the important advantage of Open Source on the server side is that my data is in an Open Format - because I have the source. I can clean up corruptions or load old backups because I know exactly how the server reads the data.
Also, I can use the same database version forever. I have to get someone to patch the code to run on Vista or Windows Server 2025 or whatever in the future, but the core of the database server remains the same. Database servers just keep running on some server and are forgotten until suddenly someone makes the decision to upgrade those old NT 3.51 servers ASAP. If you run an ancient version of Oracle, you are stuffed. No support for the old version, your proprietary front end application doesn't support the Oracle versions that run on Win2003 - so what do you do? Run your business critical RDBMS at an unsupported version on NT on VMWare on Win2003? With Open Source, you can patch the layer that needs fixing, without changing the rest of the product or include the feature bloat the Oracle Sales keep getting added into their products.
What is the sound of one hand clapping?
cat
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?
Oracle has features that are absolutely essential to some projects. And MySQL and Postgres are slowly (or more quickly in the case of MySQL) adding features, turning Oracle into a niche product.
You make it sound like MySQL is ahead of PostgreSQL in the features department. While it is true that MySQL is currently adding features faster than PostgreSQL, it's because most of those features that MySQL has been adding have been present in PostgreSQL for years.
MySQL is largely playing catchup.
*sigh* back to work...
For those cost-conscious users, you may want to explore the free Oracle Database 10g Express Edition.
e /xe/index.html
http://www.oracle.com/technology/products/databas
Oracle Database 10g Express Edition (Oracle Database XE) is an entry-level,
small-footprint database based on the Oracle Database 10g Release 2 code base
that's free to develop, deploy, and distribute; fast to download; and simple
to administer.
It is absolutely free. It has certain size-restrictions but they should be enough for a lot of usages.
Slony I requires a primary key on all tables in order to be able to do anything. I have tables that don't have primary keys and I don't want to ever have them. I've normalized my DB and it's the best way to keep track of multiple items for a single person. OIDs are a waste of time in this situation and a cop-out. I don't want to rely on some level of replication that runs on top of the database server, I want it to be part of the database server so everything that works with the DB is aware of replication needs.
Postgres really needs some replication or mirroring mechanism built-in in order to even begin to attract people away from Oracle. The Slony II project will certainly require this level of integration, and I hope it succeeds, even it it takes until PostgeSQL 10.0.
Post gre ess que ell
Post gres SQL
Post gres QL
Anyone who has done enterprise level web-enabled applications can easily tell you the faults with all of the major players in the database field. Oracle is simply 'ok', but for most tasks, it's -to be brutally honest- over kill. Do you really need the replication features of SQL when all you are doing is cacheing emails and collecting messages from your users? At this juncture, most people are relieved because they believe that they settle for a second-teir solution such as MYsql and save the licensing fees to boot.
This might be ideal if all that you were doing was a ruby program that indexed your record collection, say for a student project in your CS class; but in the real world if you have to interface with serious e-commerce applications you will find that not only does MySqL lack even moderately advanced SQL features, but that you will be facing rising support costs for this "free" platform.
So, this brings us to PostGRESL. Now, I don't have a lot of experience with it, myself, given that I've mostly stuck to following the major database players instead of the fringe ones, but since this article addresses it, I've asked some of my friends their opinions. While it's featureful and scalable enough to meet the demands of your average medium sized shop, they've noticed that it tends to not be a viable solution for larger projects. In particular the latest industry benchmarks show PostGREsqL performing poorly compared to more mainstream vendor such as ingres.
Again, like MysQl, POSTgres demonstrates that in order to get enterprise level performance out of hobbyist level software, you're going to have to pay enterprise level fees for support as well as licenseing.
So, in conclusion, after seeing the way in which the other industry standard database solutions fail, there's only one choice a sane IT manager can make: When you need a datacenter solution which both high performant and scalable, is eoconomically viable and contains more support for the current standards the only real contender is SQL Server.
"I like how I can look at the Postgres source code, so I don't have to call anyone to solve my problem - or I can choose who I call."
.001% of the elite programmers who can do this on the fly, (b) ex-developers from the PostgreSQL team, or (c) nerds in their basement with no time constraints because all they're doing is running their Star Trek fansites with it.
In discussions like this, availability of source code always comes up.
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.
No, seriously. I REALLY want to know. I can't imagine things operating at a pace where this kind of thing is even an option.
The only conclusion is that people who actually do this are either (a) the top
Next week on Slashdot:
Movers: 18 Wheelers and Pickup Trucks Debate
Grave Diggers: 360 Degree Excavators and Shovels Debate
Firefighters: C-130s and Hoses Debate
How about a site that shows me objective views Oracle, PostgreSQL, MySQL, etc. have to offer?
Just go to that site that has the unbiased comparison of emacs vs vi (can't rembember the url), then click on the "Perl vs Ruby vs Python: An Ojective Analysis" link. On that page, there is a link to exactly what you are looking for (It's just under all the "Linux vs Microsoft: TCO" whitepapers.)
...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 too have been using PostgreSQL since 6.5. I have experience with every version from 6.5 to the current 8.1....
:-)
The article made a number of mistakes or maybe the interviewees were not that knowledgable:
Jim Allen, a longtime Oracle professional and an independent technology consultant, says he has had considerable experience with PostgreSQL 7.4 and 7.5, but not the newest version, 8.0.
7.5 never existed. It was renamed to 8.0 shortly before entering beta. Goes to show how little he knows-- like those people who used to call and ask for tech support for "Windows 97" except a DBA should know better....
On the other hand, Allen was unimpressed by the fact that in PostgreSQL, stored procedure parameters are not typed.
"Everything is passed as strings, even integer arrays," he said.
Huh??? This is plainly incorrect and has been since I have been working on stored procs in it (at least 7.0, maybe 6.5 or earlier). All parameters are typed. They may, however, be presented as text depending on the function and how it is called.
PostgreSQL doesn't behave as nicely as Oracle when the system fills up, Goulet said. In those instances, the system tends to crash quickly.
I assume he is talking about oid/xid wraparound issues. Oid wraparounds fail pretty gracefully. In 8.1, you will get plenty of warnings before the xid wraparound forces a crash. However the crash is there as a safety measure to protect your data-- if the xid was allowed to wraparound, previously committed transactions would become invisible.
The solution to the xid wraparound is simply to do regular mainetnance. With 8.1 the autovacuum capability is integrated into the database backend and so this should never be a problem.
Goulet said that setting up a TCP/IP connection capability with PostgreSQL is hardly an intuitive process. To do it, he says, one needs to modify the postgres.conf and pg_hba.conf files manually.
Prior to 7.4 I think this was the case. With 8.0 and 8.1, only the pg_hba.conf needs to be enabled though you *might* also want to allow the system to listen on addresses other than localhost. In this case, you might need to alter both files.
But then there are webmin plugins etc. that allow you to modify the pg_hba entries from a web interface
LedgerSMB: Open source Accounting/ERP
Just to plug my favourite itch..
PostgreSQL needs a reliable, well documented method for performing live incrememental backups. As in:
1) dump the whole database once a day
2) dump the transaction log every 5 minutes
You can then recover to any point give or take 5 minutes by loading the last full dump and each of the incrementals up to the point you need.
PostgreSQL ALMOST has this in the form of "Point In Time Recovery" but..
1) the documentation is incomplete - key details (like a definitive method for identifying the current log file) are missing. Check out the threads in the postgres-admin mailing list. It needs to be easier and users need to be 100% confident that they have the right set of files.
2) you can only backup and restore the whole server instance - ie ALL the databases at once. In practice this means you need a second server somewhere to do recovery on, then need to perform a complicated migration back to the primary server.
If backups don't really matter to you (or you're not running a transactional system) then PostgreSQL is fantastic. But if it's getting many updates a day and you care about recovery (so you're not boned when someone forgets the WHERE clause in a DELETE/UPDATE command) then it doesn't quite cut the mustard yet.
An official reference implementation backup & restore script would be a good start.
No, I did not read the f***ing article!
Except that it was not a fork. It started on its own, but at the same lab.
I prefer the "u" in honour as it seems to be missing these days.
Postgres doesn't have built-in replication, non-commercial, yet MySQL has had it since 3.x and they are on 5.x now. Yes, there is SLONY, but it's an add on.
Do you really want to tie your replication version to your database version? As long as it is not so tied, it makes it possible to replicate between different versions of PostgreSQL (say for a zero-downtime upgrade, or a phasein of a new version) without worrying so much about forward/backward compatibility issues on the replication side.
Slony may be an add-on, but it is hardly third-party. It was written with the help of at least one of the core PostgreSQL developers.
Finally, PostgreSQL *does* have at least one replication technology, dbmirror, as a part of its contrib package which is shipped with the source.
Postgres has had views, triggers and stored procedures for a while now, and MySQL just got them in 5.0.
PostgreSQL still has more features in this area than does MySQL.
* Multiple triggers per table
* Stored procs in arbitrary languages
PostgreSQL also has roles, better foreign key support (there are some ways of adding foreign keys that MySQL 5.0 w/innodb silently drops even in strict mode).
PostgreSQL has had data partitioning possibilities since 1995, but the new check-constraint-based optimizations make it more useful in data warehousing operations.
MySQL had 64-bit support (I love the Opteron) since 4.0; Postgres just got it in 8.1. The ability to utilize large amounts of memory is a big deal for databases.
Funny, I was not aware that the Opteron was the only 64-bit chip out there. I was aware of plenty of huge DB's running on 64-bit Alphas and the like and the recommendations of 64-bit chips on large DB's was documented in PostgreSQL at least as far back as 2000.
Also, I would point out that source builds for PostgreSQL on the Opteron were shown as effective at least as of 8.0. I would not be surprised if it was not working on the platform even earlier.
The biggest issue for me prior to 5.0 was the silent truncation of *numbers* by the database. The database is your last line of defense against bad data and it should not be changing the data in order to avoid providing errors to the program. Even in 5.0, strict mode can be turned off by the client so it provides very little protection at all.
The other issue I find is that if you have a large number of database users, mysql permissions become a pain.
MySQL is a *perfect* database for content management. But for anything where the integrity of the data matters, I am not sure I would trust it.
Also, there is a new movement in PostgreSQL to move as much functionality out of the core distribution as possible and kernelize it. Thus, for example, pl/pgsql could be upgraded without upgrading PostgreSQL. Thus many of the community projects (such as PL/J) will become increasingly important. MySQL because of their licensing system will never be able to go this direction.
LedgerSMB: Open source Accounting/ERP
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 think you forgot a few important things.
Postgres has realized for many many years that February 31st is not a real date. MySQL only recently realized that.
Postgres has thrown errors for years if you entered out of bounds data. Until extremely recently, MySQL would happily silently change your data to something it liked. No errors, just bad data. Yummy. And it will still do that if you don't run it in 'strict' mode (not the default, except on windows). Postrges doesn't have any such setting to 'accept bad data and silenty change it'. Real databases don't.
Oracle's rich feature?
You have to be rich to buy Oracle. That's the feature.
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!