Open Source vs. the Database Vendors 183
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 (Score:1, Interesting)
Large Wallets + Small understanding = nothing new. (Score:5, Interesting)
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
Re:I like my 3 CD DB downloads from oracle (Score:5, Interesting)
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.
Can't hear you... la-la-la (Score:5, Interesting)
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 (Score:3, Interesting)
Re:Obvious (Score:5, Interesting)
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 (Score:5, Interesting)
Re:I like my 3 CD DB downloads from oracle (Score:3, Interesting)
Re:Obvious (Score:3, Interesting)
This is a really good argument for letting developers decide the technology rather than managers. Personally I would generally choose Postgres because I like the way it works and I have a good knowledge of it. MySQL would be up there on my list as well. I've used SQL Server (and just about all the other commercial offerings) and found it to be good but over complex for a lot of applications. Any developer that is writting detabase driven apps should be at least familiar with most commercial databases and Postgres and MySQL and able to make a decision about which to use.
Re:Large Wallets + Small understanding = nothing n (Score:3, Interesting)
I agree 100%. I have worked on plenty of development jobs where management wanted to use SQL Server (normally) or another big name database because they thought they had a lot of data. Typically we were storing a few hundred products and maybe 10000 orders. I voiced the opinion that that wasn't much data and an OSS database such as Postgres or MySQL would easily handle it. I've never recieved such dirty looks. I think the managers want the prestiege of using a "real" database.
Re:Hands on source code (Score:4, Interesting)
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.
I've been fighting to get this done. (Score:4, Interesting)
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.
Re:It's the data... (Score:3, Interesting)
What kind of guarantees do they actually provide? For all of Oracle, IBM, and PostgreSQL the likelihood of a hardware error is far greater than the likelihood of a software error that leaves the database inconsistent.
So what, will Oracle pay you money if a software failure occurs? What about a hardware failure?
From a technical standpoint, PostgreSQL is probably more trustworthy when it comes to data integrity. Oracle is often installed on better hardware, but that's not the fault of PostgreSQL.
Re:It's the data... (Score:3, Interesting)
you are very wrong. MANY companies depend on MySQL in the ways you mention and by spending the cash you saved into hardware I also can guarentee that the transaction completed or it didn't when the lights go out.
It's called decent hardware, decent Backup, decent UPS. my servers can run a FULL 45 minutes on UPS before they haveto start shutdown proceedures. coupled with Battery backup RAID cards and a raid 51 and I got huge stability in hardware for the cost of the DB.
You act like nobody but some 13 year olds with a website use MySQL. I suggest you take a look at the mysql website and educate yourself with their information.
Re:I like my 3 CD DB downloads from oracle (Score:1, Interesting)
Most people buy Oracle because that's what the application they use requires. Developers don't need to buy an Oracle license to write and test their software, so many application developers just use oracle because its there, it's got the recognisable name, and it's (to them at least) free. Its only when the application is rolled out that Oracle starts to milk the end user.
Standard Edition One (2 CPUs) and Standard Edition (Up to 4 CPUs in a box/cluster) are almost reasonably priced, but once the server or cluster has the CAPACITY to take more than 4 CPUs (cores) you are into Enterprise Edition Territory. Given that all real CPUs are now dual core, that means anything more than a dual socket system board and better start planning that first born son to hand over to Oracle.
What we are really seeing is that people are shying away from larger boxes if they have to run Oracle. Why would you spend more than $10k on hardware if it means $100k in licenses, and 20% additional per year in support? And despite the cries of "big iron is dead", there really are situations where vertical scaling will kill horizontal scaling. Plus the savings on the hardware are meaningless if you are paying a 50% premium per CPU to run Oracle RAC.
Oracle preach Linux, which is good, but only because they see that every dollar that you don't give to Sun, IBM or HP is an extra dollar you can give to Oracle, which is bad. For the same reason they have their own global file system (warning: do NOT use this yet!) and are planning the Oracle OS. Again - don't give any money to Veritas or IBM or HP or Sun... give it to Oracle.
The people to beat up on this one aren't the customers. Its the application vendors who don't realize that every dollar that their customer doesn't give to Oracle is a dollar up for grabs.
Open Source Software is not free (as in Beer) (Score:1, Interesting)
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
XA / 2PC support still lacking... (Score:3, Interesting)
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.
Foxpro? You're on crack! (Score:3, Interesting)
You misspelled "hell no".
The problem with FoxPro is that people come to depend on it, and start building their internal applications around it without realizing that it doesn't scale.
I don't mean that it doesn't scale well, but that it simply doesn't scale at all. Since it's not a database, but a single-threaded client app that reads and writes files off a fileserver instead of making remote queries, doubling the number of users doubles the amount of network bandwidth you have to use. If twenty people are accessing the same 1GB "table" concurrently, then heaven help you all.
My company depends on a FoxPro app. Without it, we go out of business. I was hired to write a web application to allow customers to access our FoxPro data, and ended up having to write a hideously complicated n-tier system [honeypot.net] where we have one VMWare image for each concurrent query we wish to be able to run. Yeah, you read that right: since the FoxPro client libraries are single-threaded, if we want the ability to execute 10 simultaneous queries, then we have to run 10 load-balanced VMWare images to service them.
So, I eventually wrote a system to copy the table files onto my local system, use a modified version of the xbase package to render them in PostgreSQL's "copy from" format, and them load them onto a pgsql server. It's more complicated in some ways than the native FoxPro query setup, but the upshot is that our queries now run between 100 and 1,000 times faster on average. Yes, those numbers are from actual profiling runs. Some queries that used to take 60 seconds (!!!) now run in a few milliseconds.
If FoxPro is the answer, then the question needs to be taken out and shot. It has our company in a stranglehold and we're doing everything we can to get out from under this twisted nightmare from hell. I honestly think you'd be better off writing applications in Excel, and that's not something I'd say lightly.
Re:Not everyone cares about Coding... (Score:3, Interesting)
There are a few classic examples of situations in which SPs aren't just not BAD, but they've very GOOD. One of the classics is anything that depends on aggregating tons of data, especially in some kind of a tight loop. Network bandwidth is not the issue here, but network latency is. You're not talking about twice as long, depending on the queries you might be talking a couple of orders of magnitude. That really, really sucks.
Having said that, 99% or more of all SPs I've ever seen were worthless and crappy.