Slashdot Mirror
Red Hat DB = PostgreSQL - Confirmed
WeaselOne writes: "Okay, it's on the record. This Cnet story cites an Aberdeen analyst as confirming that the Red Hat database will, in fact, be PostgreSQL. Also has some interesting stuff about why they didn't just partner with Great Bridge."
--
Knowledge is, in every country, the surest basis of public happiness.
All they are going to do is wrap a customized installer around someone else's hard work.
...
Gee, like they do with the kernel, X, mozilla, samba, kde, and gnome? Like what every distro does? Why should this be any different?
They're adding value to customers who want a DB with support. This is open source, they can do this, and I bet $20 that the Postgre team is happy to be part of the package, since this will expand their market and get more people interested in postgre
So why PostgreSQL?
Red Hat needed to choose one that existed. Building from scratch, no matter how you look at it, would provide little return on investment.
They had a relationship established, with a group of developers very familiar with the product. Is it the best choice for everything, of course not. Hence the reason we have DB2/2, Oracle, MySQL...
What does Red Hat get out of it?
They have a core group of developers in place today. Zero cost of a learning curve for them and minimal for the developers they add. In addition, they get PR. Red Hat is a public company that is making money. The PR only helps.
What does the Open Source community get?
More dollars invested by someone who can work at it full time. In addition, we do not loose access to other DB choices. The development of MySQL, Oracle, sapDB, etc. will go on regardless of the announcement, either way. This will merely allow focus on this product for the reasons stated above.
To read this as a your SQL's better than mine, degrades quickly back to the NT vs. Linux sport that shows up in some newsgroup about a billion times a day. Many database options are good. Many are good at some things the others are not. I try to equate these choices like cars, we all want to drive different things for different reasons.
If you take a close look at the benchmarking on the InnoDB site, you'll notice their comparison against Postgresql is only measuring speeds with a since query running against the database. Likewise for their MyISAM vs. InnoDB test, and their MySQL vs "market-leading database test".
So all of these suffer from the same thing that the default MySQL benchmarks do - they're meaningless save for marketing. There are very few real world applications that are going to have serialized queries, and those that do are likely not going to require a lot of raw speed.
If you'll notice, the only test that they use multiple connections with is their scalability test, in which they make no comparison to other databases, and that showed performance dropping sharply on selects after 50 clients, and didn't even bother giving performance on more than 20 for inserts (I'd be interested in knowing whether they were just embarassing or if the server actually crashed).
And none of the tests include a mixed load of selects and inserts. And they flat out admit their methodology was different for MySQL and the contender in one test. And they ran all of it on a single server. And none of the tests include large tables, joins, transactions, sub-selects, etc, etc. The number of faults with their benchmarks are innumerable.
Part of the beauty of the newer releases of Postgresql (aside from the improvements to the query optimizer) is their new "no-locking" MVCC (Multi Version Concurrency Control) system. Selects NEVER block inserts and vice versa.
This is a _huge_ win in terms of performance in real world situations; coupled with the row (or even cell level) locking pretty much guarante better scalability than MySQL, even if running a table type that supports finer grain locking (I believe the best they do right now is page level).
I like to think of MySQL as a sports car. It'll get to zero to sixty faster than an 18-wheel truck. But if you try to put any load on it, it won't even more.
(Note - the company I work for uses MySQL for a large production database. And it has worked even for a fairly large database under a somewhat heavy load. However, it is performing adequately, not well. And there are a lot of things we simply CANNOT do (e.g. a large query against the database for statistics purposes, since the select would lock all inserts and deadlock the database. Even under normal load its not uncommon for us to see 20-30 selects locked waiting for an insert to complete).
And to be honest, even if MySQL performed half as well as their documentation implied, I find the lack of features like sub selects, select into table, transactions (under the heavily tested table types), stored procedures, triggers, foreign keys and views make it a waste of my time and a waste of the programmers time.
We have dozens of programs and scripts that all have to access the database and they all have to work around the deficiencies in MySQLs capabilities. And, to be honest, not every attempt to do so is ultimately successful, resulting in hours wasted doing cleanup work (when it actually CAN be done without killing the database.).
I don't begrudge other people their preferences, but it would take a LOT of improvement and real benchmarks to convince me MySQL is a better database.
Matt
Doubtful there will be any immediate benefit beyond simply coupling Postgres with RedHat, other than the RPM integration you mentioned. In the long run though, consider how Microsoft has put SQL Server to work for them. Pretty much every product they label "Enterprise" somehow integrates in with their database server.
As RedHat goes struggling for the "Enterprise" market, having a known database running under the hood is going to become more and more critical. Anything they can do to simplify the process of getting that database up and running quickly is also a major selling point over other solutions.
Personally, I mostly use MySQL for stuff. I'm a simpleton, and it's nice and simple. For what RedHat is looking to do I doubt there's a better choice out there than Postgres. That, and if Postgres gets a nice influx of new dedicated developers this should be great news for both RedHat and Postgres users.
The line must be drawn here. This far. No further.
Gee, like they do with the kernel, X, mozilla, samba, kde, and gnome?
I know you're not attacking RedHat here, but I felt I should note that they do a bit more than just wrap stuff together. They've got a lot of folks doing development work on a number of those items mentioned.
I don't personally use RedHat here, but I do have a great deal of respect for them as a company. From what I've seen, they appear to be very straight shooters that have managed to not only lead the Linux market, but also maintain a great deal of repectability while doing so.
The line must be drawn here. This far. No further.
For Redhat, the idea of building a database would be a bad for bussiness on their part. First off, they would piss off Oracle and IBM and we need their support to move linux to the enterprise. Second, Redhat finally made a profit and why develop something with no instant return? If enterprise users need something powerfull Oracle or DB2 would be there. right?
.NEt/hailstorm :-) ), cheaper, and hopefully more powerfull. I assume redhat will come out with its own threading scheme and might put some limited functions in the kernel like what they did with TUX. SQL server is faster because its in the kernel and its supprising stable because they made sure to only put the indexing routines in the kernel and not memory managment in SQL server. We need real competition before ms guts Oracle from the bottom up.
.ocx for easy development for all the VB zombies, then I will be happy.
But after reading the CNET article and figuring out what market they want to go after it makes pefect sense. Microsoft's strategy is to scare IT managers buy showing a product get better and better to make them think its going to gut competion from the bottom up. Remember Scalablity day 5 years ago? Ms demonstrated transaction server handling a million hits a day with transaction server/wolfpack on NT4 on a dual pentiumpro 200. IT managers noticed it ran well in low end hardware and they thought "wow, if NT can do this on pc hardware, think about what it can do with higher end hardware! In 5 years unix will be dead!". It worked! Overnight NT4 became a best seller and many doubted that unix would ever survive. Today its laughable but the marketing worked and they are using a similiar strategy with SQL server.
SQL Server is practically the defacto standard already in any mid-range or even department database. MS is gutting them from the ground up. IT managers still have the all ms craze of 5 years ago and Oracle/sun or db2/as400 is pretty expensive and is used for large operations and is slower in midrange use. This is why Oracle bans the use of benchmarks. Sql Server is serious competition and is getting better. Sql server is supprising stable where I work and it went down only once in 3 years!
IT managers who buy redhat use it for a quick webserver installation or cheap department server. SQL server is cheaper to buy and implement for a bussiness database and it has support for odbc, ADO, oledb which are all becoming the defacto standards. Postgres as it is today has some limited odbc support, is not scalable, hard to set it up to handle a real load. I have no idea how Rob Malda even managed to run his site with only Mysql. Contrary to poular believe here on slashdot postgres, and mySQL are great for development but suck in real bussiness situations with hundreds of users. PHPbuilder.com did a benchmark and showed mysql having trouble with intense SQL calls with only 30 users. Since database access is essential for any web/intranet, messaging, or client/server app we need to have an alternative with great odbc, ado, oledb support as well as JDBC.
The problem with SQL Server is it doesn't support JDBC (wonder why) without an expensive third party extension. Servelts are pretty standard for retreiving data on intranet/internet servers. So if you have java servlets running on an intranet server you need a real database but only expensive oracle/sun or db2/as400 is available for real bussiness use( I assume 500-1000 users)?
Microsoft's answer is c#.net or VB.net applets running on SQL.NET wich is cheaper and fully integrated. You can also save development time by writing the apps in Visual basic and that alone could save for the cost of the servers. Sorry Redhat but most IT manangers would choose MS in such a situation.
With a real midrange database there can be a more economical solution thats more fault tollerant (if connection to the web dies, the server goes down in
IF redhat can accelerate postgres, and make it scale to many processors, support oledb, odbc and
http://saveie6.com/
Yes sir, we folks at Red Hat, known for the Red Hat Linux Distribution, RHCEs and enterprise-level solutions, are now packing with every forthcoming Red Hat distribution a Red Hat configured database solution for low- to middle-tier database needs. The RHDB will be specially customized for Red Hat systems, which are put out by Red Hat, the most prominent Linux distribution on the market today.
You laugh, because it seems obvious here, but I remember taking a look over at a Microsoft story on MSNBC, and found no less than 75 instances of Microsoft branding, using "Microsoft" or "MS" or "Windows". And this was for one story, on one web page.
Any new avenue that Red Hat can use to drop its own name is an opportunity to solidify mindshare. Entering the database arena with a core product that won't embarass them is a no-brainer. They've even got GTK+ experts in-house that can make the thing look pretty.
This could be a SERIOUS hit to MS Access and SQL server. And with Postgresql functionality built straight into php, the whole MS-IIS-ACCESS/SQLS-ASP combination can be easily matched in terms of quality, performance and reliability by Linux-Apache-RedhatDB-PHP combination, totally surpassed in terms of cost, and only lagging behind a little bit in the gui department. From a marketing standpoint, it makes the solution LOOK more cohesive (even if it isn't), and that's always been the selling point of going with an MS solution -- smart move by RedHat. And with the GPL on their hands, we can trust them not to be sluggish and proprietary in terms of responding to the community's needs -- good move for us.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Bwahahaha. You must be kiddin' me. Once upon a time MySql was better - but only in terms of performance. But - MySql has been plagued by the fact that they never implemented foreign key support into their DBMS. The MySql documentation speaks of foreign keys as if they are a bad thing. Which is of course a joke because everybody who has studied DBMS's seriously, knows that foreign keys are an integral part the relational database model as it exists.
Now, I ask you, why would the MySql designers occupy such a religious statement?
Is it because they would never be able to implement foreign key support afterwards into a static design, where you just could not possibly fit it in without a rewrite of the core DBMS logic?
Mysql is mostly a way of storing your data in some kind of simple hashed form, accessible with SQL queries. That's why mysql is so fast with queries.
But I think this was never the meaning of the relation model. I can store my data in my own hashed format, and my queries would be just as fast, or faster. Mysql is just a packaged piece of software representing this simple kind of storage, which answer to only the most simplest of SQL queries.
Take postgresql on the other hand: foreign key support, transaction roll-back support, ability to plug-in your favourite query language (be it based on tuple or domain calculus or relational algebra like sql), etc etc etc. With the added bonus that PostgreSQL *smokes* mysql on every available benchmark that you can find, it's clear which is the better option.