Open Source vs. the Database Vendors

bhmit1 writes "BusinessWeek has another spread on open source this week. Among them is an article about open source vs. the database vendors which focused on how businesses are looking to save money with open source (rather than using the source to innovate). From the article: "The databases work fine, but as data volume grows, so do the checks to Oracle, IBM, or Microsoft. Many users aren't clamoring for more features, and some don't even use the bells and whistles they already paid for. They would happily trade some to get their hands on the source code and a better deal." Disclaimer: that quote came from Sony."

I like my 3 CD DB downloads from oracle

Why would I want a small download from mysql?

Re:I like my 3 CD DB downloads from oracle

Do you know what hell is?

Hell is having a product you have to explain to the customer.

Customers don't understand databases, so they're not likely to understand the difference between MySQL and Oracle. And, ironically, that might mean MySQL is where they ought to be. This isn't to disparage MySQL at all, but I'm just saying you can't explain the difference between MySQL and Oracle, you shouldn't pay the difference.

You may or may not pay for your lack of knowledge later.

Obvious

... which focused on how businesses are looking to save money with open source (rather than using the source to innovate).

Duh. Isn't that the #1 draw for the majority of OSS users out there? Sure there are some that are in it for the politics and others who actually try to contribute, but let's face it, the majority of people use it because it's free (as in beer).

Re:Obvious

It's certainly the only reason businesses choose OSS, or proprietary software. Net present value of TCO over the planning horizon.

Until now, the free databases lacked accessibility for "drive by" business users. You don't have time to explore every option, even if it might lead to a better decision. Install Unix to check this thing out? Not today thank you.

MySQL as it now stands is probably the simplest real RDBMS for the casual shopper. It's just as easy as MS SQL server, and MS is the only vendor who understands the importance of the casual shopper. Postgres is not far behind.

Re:Obvious

MySQL as it now stands is probably the simplest real RDBMS for the casual shopper. It's just as easy as MS SQL server, and MS is the only vendor who understands the importance of the casual shopper. Postgres is not far behind.

Actually, have you tried installing the latest "light" versions of boh Oracle and DB2? They're dead simple to install and administer. Not to mention writing the actual apps. They now have pretty much drag-n-drop GUIs for app creation. I think most vendors are now realizing the importance of this group of buyers.

depends

I think it depends upon the scale. There are probably many small users out there looking at OSS databases to save money on licensing. And these types will be very happy to jump on board to a 'free' proprietary product. But there are some large companies with the resources and the desire to leverage access to the source code. A good example that comes immediately to my mind is Fujitsu's involvment with PostgreSQL.

Large Wallets + Small understanding = nothing new.

In my work experience, I have concluded that the vast majority of "big name" database users vastly underutilize the features that the big bucks pay for. Many companies that generally only need a step up from MS Access but get sucked into Oracle or DB2 thinking that's the logical next step.

In addition, many database users don't have a realistic understanding of what constitutes a lot of data. I've met quite a few people that think a 10k row database is huge, and anything in the 1 million record range is absolutely gargantuan! To me, anything less than 1 million records is downright tiny. Seriously, many of these users don't need an "enterprise" RDBMS for scalability reasons, which is what leads many customers to open their wallets. Something like Postgres or MySQL would be more than adequate for their needs.

That is not to say there are not users who need the enterprise features, but it amazes me the amount of money that is dumped into features that most small to medium size deployments don't even use.

It is very educational to see how Oracle for example is used in real world deployments. Open source aside, I have seen many where the user may have been better served by just using a properly setup MS Access or FileMaker database!

-Pete

It's the data...

The user says "This is vital". IT staff start adding zeros to the price tag of the application. Seriously nobody in the IT dept is ever going to suggest something like mysql or postgresql for something like the corporate accounts or other financial transaction backends because people like IBM and Oracle guarantee that when the power goes out, the transaction completed, or it didn't happen at all.

And if you've paid for Oracle/DB2 and you're training your staff on and using Oracle/DB2 anyway then it doesn't make a load of sense to introduce different RDBMS systems that your DBAs and administrators are completely unfamiliar with, especially when you've got that Oracle box sitting there underutilised.

Ultimately you're right, 95% of apps could be served perfectly well by mysql, postgresql, msaccess, filemaker etc. Corporate IT depts should really create two categories of RDBMS systems, vital and casual. The vital ones being the core business operations and casual being everything else.

 

I've been fighting to get this done.

The user says "This is vital". IT staff start adding zeros to the price tag of the application.

Yep. And it is up to the requesting user to justify spending that money to the CFO.

It is not IT's job. IT just gives everyone the pricing based upon how many 9's of availablility you want and the database/server licenses.

If the user balks at that, the database can be put on the far less expensive PostgreSQL/mySQL server.

The downside is that the database people need to become familiar with TWO different databases (or more depending upon the other apps).

The upside is that the company saves a LOT of money in licenses and such.

Not everyone cares about Coding...

It may surprise you but most people who use open source applications do not change the code. Even the ones who know how too, don't. Why, because they don't have the time. They download it try it, if it does what they need they use it, if not then they try an other product, if they cannot find an Open Source tool that does the job then they see if there is a commercial one that does. Programming takes time, even an open source application, time costs money, so if paying 2k for MS SQL Server vs. 3 weeks of development, to get the functionality they need they will just get MS SQL and they will save money. Plus this time could be used by the programmers to create business critical code (Which earns $$$), vs. IT Infrastructure code (which costs $$$, but may save $$$$ in the future). As some of your open source developers may or may not realize your cool feature may not be used by anyone buy yourself. Heck I have a hard time to get people to used Stored Procedures in their SQL, needless to say trying to get them to use the more advanced features.

Re:Not everyone cares about Coding...

That this gets modded insightful is an embarrassment. Every DBA worth two shakes of a dead rats ass can tell you putting stored procedures in the DB cuts down on network traffic and improves application responsiveness. Every time a query is passed across the network it has to be compiled to p-code. Multiply that by X users and the system grinds to a halt. Ease of implementation and clarity also shoot through the roof with proper use of stored procedures. And the scalability problems you speak of don't exist, since you can instance your database just like your app server.

The Slashdot hive mind may not like the idea of being tied to a particular database or vendor but in the Real World businesses choose their databases carefully and stick with them for a long time, often forever. With this in mind you exploit every single option available when programming and stored procedures along with proper filesystem layout, column indexing and schema design are key to a high performance database.

Can't hear you... la-la-la

The wild card in all of this will be whether big, successful tech companies get behind the upstarts. Linux hit prime time only when IBM, Oracle, and others got behind it, rewriting their software to make it compatible and convincing worried CIOs that it was robust and reliable enough to entrust their business to it.

A company such as SAP (SAP) could be pivotal. The German software giant is locked in an applications war with Oracle, but the bulk of companies running SAP applications run them on Oracle databases. So even when SAP wins an application deal, it's often making money for its archrival. That doesn't sit well with ultracompetitive SAP, which already has a burgeoning partnership with MySQL. Closer ties there could mean more SAP applications on MySQL databases. Elsewhere, Red Hat (RHAT) has endorsed both MySQL and Postgres, as did Sun Microsystems (SUNW) last November.

So Oracle has now become Microsoft, pretty much resting on its laurels and claiming that its users are more than happy with them, while all-the-while, their users are shopping for cheaper and better solutions. If SAP were to out-and-out declare they like MySQL better and shift most of their DB usage there, Oracle would have a very large amount of egg on their face.

Let's face it: when you become the dominant leader of your industry, you tend to forget what got you there and you take it for granted you will always be there. I've used Oracle, MySQL, and Sybase, and I find the latter two to be a lot easier to work with than Oracle. Oracle is trading solid dependability for tricks and gimmicks, and in the end, no one wants to pay that kind of money for things they don't need or won't use.

Open Source + the Database Vendors

I'd love to develop my apps with Postgres, then deploy to Oracle or DB2 with an automated tool. If Oracle or IBM distributed a free (beer) one, I'd include it in my project plans. And if there were an open source tool for comparing performance of my app on each of those databases in real tests, I'd be more likely to make the switch - provided the tests showed an advantage.

Re:Open Source + the Database Vendors

You ARE joking, right? Oracle is free to use for development, just not production. If you really use Oracle, you should already know this.

Hands on source code

From the article: They would happily trade some to get their hands on the source code and a better deal.

How many are there who would actually look at the source code of a database, work on it rather than develop new applications based on it? If database A works, then they are going to stick with database A until conditions change drastically. It hasn't happened now and doesn't seem like it will happen in the near future.

Re:Hands on source code

From the article: "They would happily trade some to get their hands on the source code and a better deal."

How many are there who would actually look at the source code of a database, work on it rather than develop new applications based on it?

Let me rephrase the excerpt from the article:
"Some users would happy forego certain features present in commercial databases if (1) it means reduced cost and (2) you access to the source code."

Why stick with expensive Oracle or DB2 if PostgreSQL does the job reliably enough and it's free? That's a no brainer.

I think you're asking, "why even look at the code if it's working?". Absolutely right. If it ain't broke, don't fix it.

But, if there's a feature missing that you require, then for certain businesses -- not all -- it may well make sense to add code yourself. A tech company may underutilised coders on the payroll: it may be cheaper to get them to code and support that feature than it is to sack them.

A large corporation (Sony, 3M, etc.) might need to deploy that feature in hundreds of places. Paying someone to code it gives them a lot of bang for the buck.


If database A works, then they are going to stick with database A until conditions change drastically. It hasn't happened now and doesn't seem like it will happen in the near future.


Successful businesses always look to reduce costs. If database A works, database B is $10,000 per year cheaper to license and support, the migration will cost $20,000 and you expect to continue using the system for over 2 years, then (cashflow allowing) it's a no-brainer to move. The only thing stopping you would be lack of business agility.

Well

I think most businesses crave accountability & reliability more than anything.

I'd be more comfortable running a system running a vendor dbms rather than an Open Source implementation - just because when shit hits the fan (which it invariably does), at least there's ultimately someone responsible for it.

Don't get me wrong; we run mySql for all small-midsize operations, but the bigger systems run Oracle purely because of this reason.

Short Term Gain Is KING!

which focused on how businesses are looking to save money with open source (rather than using the source to innovate)

This is a surprise? Maybe "back in the day" innovation was a significant part of the average business plan in the United States, but those days are long gone in today's business world where short-term financial gain is the only objective. Realistically, the only innovation going on today it that which is related to military use. Sad, really.

But who will my boss shout at?

If we use an open source app my boss will have no one to call up and shout at when things go wrong. Thus, any suggestion to use an open source DB will be pissed on.

SAP

At my company we are making a move to MySQL in order to accomplish what SAP cannot do for our assembly lines. This involves keeping track of incoming and outgoing material. SAP will still keep track of what happens with the finished goods, and received parts. Why we keep SAP probably has something to do with the corporate jacuzzi.

MySQL at $40 million per year. And that's fine.

So MySQL generates only $40 million in revenue per year. That's OK. That's enough for perhaps 400 people. How many programmers do you really want working on a database? Beyond 50 or so, they'll probably add more bugs than they fix. And they'll be tempted to put stuff in the database that shouldn't be there.

Of course, this is a problem for Oracle. Building Larry Ellison's house cost far more than MySQL generates in profit. I drive by the place all the time. Under construction, it looked like a mall. Oracle stock dropped from $50 to $12 while the house project was underway.

It's all about the DBA

We use MySQL, Postgres, SQL Server, Oracle and DB2.

Out of all of these product, the best DBA we have is an Oracle guy. He really knows his stuff. It is the smoothest and easiest to program for because he can answer the questions we ask. He's also a really good programmer, so he can debug the stupid mistake done by the contractors(Ok, I might have made some dumbass stuff myself).

If I had my choice, I'd use Oracle everywhere and promote him to manage it all. He has shown me that no matter what you use, it;s only as good as the support you get from your DBA.

Open Source Software is not free (as in Beer)

I don't work for a database vendor but I find some comments above about open source databases optimistic. MySQL is fine for small and mid-size companies but I don't see large corporations letting go of commercial database products any time soon. Even if they've never heard of OLAP or Grid databases they will most likely choose Oracle or SQL Server over MySQL any day.

Here are some costs associated with open source databases which you may not have thought of:

1) No Support - what happens if your developers run into an issue with the product or your production system goes offline. Who do you call for support? Who do you call accountable for project failure (worst case bankruptcy)? Nobody wants to resort to online forums.

2) There are many Oracle, SQL Server and DB2 specialists on the market. Finding a MySQL expert for support staff is much harder. You need years of specialized work experience to be an expert.

3) As an early adopter of software you take on the risk while others (including competitors) learn from your mistakes. It's easier to follow someone else's success then wandering around on your own.

P.S: I do most of my development work with Oracle (with .NET and Java projects), but I've used DB2, SQL Server, MySQL and PostgreSQL. If you think Oracle is not user-friendly try using TOAD or DBArtisan - both are fantastic.

Sure it is

No Support - what happens if your developers run into an issue with the product or your production system goes offline. Who do you call for support?

Whoever you paid for your commercial MySQL [mysql.com] or PostgreSQL [postgresql.org] support contract, of course.

There are many Oracle, SQL Server and DB2 specialists on the market.

So your contention is that a high rate of turnover in the support of those applications is good?

As an early adopter of software you take on the risk while others (including competitors) learn from your mistakes.

MySQL and PostgreSQL were publically released 11 and 17 years ago, respectively. If that's your idea of "early adopter", then may I also suggest other hip new technologies you might wish to investigate, such as TCP/IP, VGA graphics, and transistor-based memory?

XA / 2PC support still lacking...

The open-source RDBMSs *are* catching up to the closed-source databases, but there is still plenty of work to be done. One area in particular is support for the XA protocol for 2PC.

Both of the "big two" (MySQL & PostgreSQL) advertise XA support, but neither has complete support; as both fail to support suspend/resume. And while this might seem like a minor point, XA support is an absolute must if you want to do something like incorporate a database write and something like a JMS message into one transaction. Currently you can't do that with, for example, JBoss and PostgreSQL, as JBoss' transaction manager tries to do a suspend at some point in the process, resulting in an exception from the PostgreSQL JDBC driver. (As an aside: I haven't researched yet whether or not this is correct behavior by the TM, so this particular example might not be a problem with a different app server).

Clearly not everybody needs this level of functionality.. but for those who do, it's critical. By way of example - imagine an enterprise CRM system which uses JMS to federate data across systems by publishing events to a Topic when customer records are modified. You really need ACID compliance for both the database write and the message publish, or you get inconsistent data which is BAD, BAD, BAD. Yes, yes, I know there are ways you *could* get around this without using XA, but the point is that this is what XA is for and this is the direct, obvious, normal way to approach the problem. And by and large, the open-source databases just aren't there yet with the needed functionality.

That said, I believe they will get there in time. And in fairness, there may be a open-source database (possibly Ingres or Firebird) which does have full XA compliance, I haven't investigated them all in detial.

Support

I keep reading that the main reason companies don't switch from closed to open software is because there are no support options available beyond internet forums, IRC chats, and mailing lists. Have any of you people making these claims actually investigated what support options are available for some of the software you use?

Granted some non-widely used software will only offer forums, chat, and lists as support options. But most major open source packages (including MySQL) does have professional level support available. Some open source companies (like MySQL and RedHat) offer commercial support themselves directly to the customer. Other packages have vibrant support communities that have sprung up around them and even companies that are quite successful offering commercial level support for several open source packages.

Saying that the reason people don't switch to open source software is because there is no support available is simply not true. It might have been true two or three years ago but not anymore. Take some time and investigate your options and you'll find there's a lot more available out there than you might think.

S-U-P-P-O-R-T

No company with a board of directors is going to bet the farm on a mission critical software product for which they cannot purchase support. You have to have someone to blame when everything falls over.

Standards

To the extent they exist, are free, functional, and that people actually pay attention to them, standards will help make a smooth transition for customers wanting to trade Brand X SQL server for Brand Y SQL server.

I'm not sure how many customers actually migrate downward from a commercial offering to FOSS options like MySQL or Postgres. Upward migration has always been a way out if you outgrow the FOSS, but you can always evaluate whether the increased performance, reliability, features, support are worth the money. That means vendors get their feet held to the fire to provide genuine value-added.

It means it will be increasingly difficult to sell plain old SQL servers to new customers if the "Good Enough" MySQL and Postgres become increasingly capable and set the bar higher and higher every few years.