Are Expensive RDBM Systems Worth The Money?

Death of Rats asks: "What are the actual advantages of high-end Relational Database Management Systems (such as Oracle) over the free or low-priced solutions? Is it worth paying the 10 to 30 thousand dollars (or more) for Oracle, when you can do (as far as I know) everything it can by using ASP with Access/MSSQL for Windows, PHP/MySQL for Linux, JSP with JDBC connections for most platforms, or any number of other free or cheap systems? Is there a considerable speed increase, or is there enough more functionality to warrant the outrageous costs? Are some of the technologies more suited to different tasks? Any time I have needed to use databases, the open-source solutions have done fine, so I am skeptical."

There is no one-solution-fits-all answer to this question, as it really depends on the requirements of the task at hand -- which will in turn determine what one needs from an RDBMS. I'm sure there are tasks out there which better suit the high-octane RDBMS systems, but what tasks do readers feel still need that kind of power? Has the distance between Enterprise RDBMS servers and the free alternatives shortened at all?

Comments

Re:Web sites != large amounts of critical data

[Anonymous Coward]

North Carolina is entrusting their medicare system to some dude writing one page porn sites, are they?

Scalability and application support

[jabbo]

What do you pay for? Well, mostly you're paying to see your pillow more often, or at least that's what the vendor is trying to sell you -- peace of mind.

I have (lately -- SQL 7, not just SQL 6.5) seen MS SQL databases that buy the farm every night and get rebooted, and this is referred to as "more stable than before". I've watched MySQL crumble under heavy concurrent read/write loads on large tables. I still haven't figured out an easy way to carve up PostgreSQL backend storage so it scales more like Oracle. And I've thus far managed to make every (yes, EVERY) database I've ever used core dump. I'm working on DB2 at the moment; apparently it runs across x86 Linux clusters, which of course is something I'd like to crash. I got Oracle 8i to crash (finally!) earlier this summer. That was unusually difficult; Sybase and Informix were relatively easier. So, when you go the commercial route, you're paying for features, branding, and a lot of stuff you already get from the free RDBMS packages. Plus, more people tend to know about the bugs (every last RDBMS I have seen has at least some bugs).

BUT when you get right down to it, even Postgresql (my favorite free database) simply does not have the application support or PROVEN OLTP scalability of something like Oracle. Today someone batted around the idea that "DB2 is okay up to around 10 or 15TB, but I talked to some banks and oil companies, and they say that beyond that, it just falls apart". It may be the case that Oracle scales a little better than DB2, but up until recently, the top 10 (size-wise) OLTP databases on earth were running NCR Teradata, IBM DB2, and I think there may have been one Oracle customer in there. UPS's database, the largest active OLTP database, was only around 12TB last time I looked.

12TB of live data is a HUGE amount. EMC's top-of-the-line Symmetrix, a piece of equipment costing a cool $3.2M, just barely fits 12TB if you're running everything mirrored. God forbid you blow out the cache on that monster. And of course there's the question of backups...

Basically, if you're tied into a vendor's specs (eg. "We only support MS-SQL here at Affymetrix" or "ArsDigita only supports Oracle as our ACS backend") then you don't have to choose, just get out the wallet and bend over. No lube for you!

Otherwise, in my neither limited nor hugely abundant experience, MySQL and Postgres work pretty damn well for read-only data marts and low- to mid-volume read-write backends.

Beyond that -- if MySQL can't handle your OLAP needs, and Postgresql can't handle your OLTP needs -- then maybe you have to look at Oracle or DB2 or whatever. But by then I strongly suspect you'll know why they charge so %$@#ing much :-).
The differences are fairly marginal, but if you need them, you need them, and that's the end of it.

Two things

[the red pen]

1. Scalability. Open-source databases, in general, haven't endured the real-world conditions that Oracle, DB2 and MS-SQL have. If I compile Postgres for an RS-6000 it should kick ass; but will it? How much will it cost me to find out that it can't hack it? When we're talking about that kind of performance, we're talking about mission critical apps. As far as MS-SQL goes, the scalability issues are that it only runs on Intel hardware (where are you going to go today if that's not fast enough?) and it eats resources at a much higher rate than competing solutions.

2. Compatability.Hopefully, you are not in this situation, but a lot of application only "work" with one database or another. Even APIs such as JDBC that offer cross-platform portability can't port your stored proceedures. If you are starting from scratch, you can avoid or mitigate such portability issues, but if you need to integrate with some other COTS, you will probably end up with a narrow list of DB's it "works" with. Chances are, MySQL won't be on the list.

You get Oracle for your 10-30K

[rho]

Like it or not, Oracle is worth every penny, assuming you can afford it. If you, or your client, cannot afford the (admittedly) big bucks for an Oracle licencse, there are plenty of free (and Free) solutions available.

What do you get with a 10-30K (or, in my experience, a 50-80K) license? You get Oracle's years of development and expertise in managaging some of the biggest and baddest installations. Think 500-1000 gigabyte DBs in constant use for 15 years.

You get a whole bucketful of trained and talented DBAs (who are worth every damn penny of there high 5- and 6-figure incomes) who grok Oracle syntax.

You get Oracle Corporation's culture (at least, I hope it's still the culture). At Oracle, the technologists create cool stuff and pay the marketing department to find or create a market for said cool stuff, rather than marketing dictating what technologies are created. Thus, when you visit Oracle, you find 3 or 4 products that do nearly similar things, or overlapping technologies. (I think this is a good thing -- others may disagree)

Finally, you get name recognition. Don't laugh this off -- it's worth a lot of money to some people. If I say "Let's do it in Oracle", people respond, "Yeah, that would be best." If I say "Let's do it in PostgreSQL", I hear "Huh?".

It boils down to: If the money is there, spend the money on Oracle, and advertise that fact. If the money isn't there, use PostgreSQL, and just say you have a RDBMS back-end.

(Oh, MySQL isn't a RDBMS in my humble opinion. It's a fine solution for certain problems, but don't confuse a SQL interface to a filesystem with a true ACID-compliant RDBMS. Future versions of MySQL promise to alter this perception, which may change the dynamics.)

Three Main Reasons

[PureFiction]

There are a number of reasons why you would pick any particular RDBMS, but I have seen three which come up most often and are of the most importance.

Support

This is a big one. And an enterprise scale RDBMS needs a lot of support. Ever wonder why some Oracle DBA's make more than skilled developers? Administration of a large database is not trivial, and these databases often run the core of a corporation. Mission critical to the extreme is common for these systems (Hence the reason Oracle can charge millions for a large Oracle Applications ERP installation)

Performace

These big databases are built to handle huge data sets. Oracle supports all kinds of direct interfaces to read/write directly from a SCSI/Fibre channel RAID setup. A number of the Oracle extensions, or custom application also have to be extremely fast given the amount of data they are working. PL/SQL and embeded SQL, OCI, etc, are all tools to allow maximum performace with large heaps of tables and rows.

Add-ons

And by this I mean extra pieces of functionality or applications that are only provided with a specific RDBMS. Oracle Applications, which is a popular ERP package, requires an Oracle database. Likewise, PL/SQL is very popular, but only available for Oracle. Add in all the other niceities that Oracle ships with 8i, and you can see why the entire package is pretty impressive.

So, in the majority of situation a smaller opensource RDBMS like postgreSQL or mSQL will probably work just fine.

If you are n enterprise customer which needs extreme scalability and performace, You would be hard pressed to go with anything other than Oracle or IBM.

ACID properties

[isomeme]

The real distinguishing characteristic of a high-quality database is rigid compliance to the "ACID properites" -- Atomicity, Consistency, Isolation, and Durability. Put very briefly, "atomicity" means that transactions either completely succeed or completely fail, with no partial changes possible; "consistency" means that rules concerning how data relates can be enforced by the db engine; "isolation" means that the db state visible to one transaction in process won't be changed by other parallel transactions; and "durability" means that changes won't disappear once they are completed successfully.

This all sounds simple enough, but producing a db that actually implements the ACID properties reliably is very, very hard. So hard that people tend to charge tens of thousands of dollars for the result.

Of course, in many circumstances you don't actually need a fully ACID-compliant db. In general, if your transactions don't involve strangers' money, and if data can be cross-checked and reacquired from external sources in the event of a problem, you can get by with a cheaper, non-ACID db server. But using a non-ACID db where you really need ACID-level reliability is asking for big-time trouble.

--

Depends on what you want to do

[Elias Israel]

High-end DBMS products provide lots of features that can make coding your web site a bit more cumbersome, but maintaining it much easier.

In particular, built-in enforcement of data constraints, triggers on data modification, and stored procedures are HUGE wins for many web sites. Using these correctly can move tremendous amounts of complication out of your PHP or ASP code and into the database where they can be more easily tracked and managed.

The lack of transactions in MySQL is often commented upon, and its very important. A complex set of related changes can fail in the middle for many reasons, leaving your data in an unknown or even a completely corrupted state.

Is it worth all of that to pay Oracle's fees? For a commercial web site, where dollars are at stake for every bit of downtime or lost data, then the answer is absolutely yes.

If, on the other hand, you're working on something that uses the database as structured storage rather than a full-fledged DBMS, and especially if you don't mind babysitting it from time to time, the cheap or free options are probably OK.

Web sites != large amounts of critical data

[NineNine]

Anyone who has ever been a DB developer (such as myself) or a DBA knows tha thte vast majority of enterprise-class databases (Oracle, DB2) are NOT used for web sites. Web sites are cute, but rarely are they mission critical, and rarely do they hold vast amounts of information. Think large systems. Cam you imagine, say, Visa or Matercard running MySQL to handle thousands of transactions a second? Or how about truly large databases? I recently set up North Carolina's Mediare system on Oracle. That started out as a 3 TB database, and will grow steadily for the forseeable future. Has MySQL ever been tested against something of that size? Even the largest web sites do NOT generally compare to other entreprise-class projects, in either size, ort he critcality of data.