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."
I've been a die-hard PostgreSQL fan for quite some time now, often having to defend my decision to go with a more robust database than the first answer off almost everyone's tongue: MySQL.
I'd like if someone could help clarify what is exactly happenning though. Great Bridge employs half the Postgres developers. They claim to have a "commercially QA-tested" version of Postgres -- what exactly is this? What does it do or not do that the stock PostgreSQL does or does not do? And now along comes Red Hat -- perhaps my least favoured distribution of all -- and says it's going to be packaging PostgreSQL in with their distro, claiming to make enhancements that make it faster with Linux. What exactly are these guys planning? Hopefully not more distro-specific kernels!
Personally I'd love to see anyone come with a way to do an online backup of PostgreSQL's databases. The current favourite is to do a pg_dumpall -o and gzip/bzip2 it out to tape. I really couldn't give a rat's ass if PostgreSQL suddenly had .RPMs to install rather than compile from source but the tighter integration with Linux intriguing. Hopefully it will be done right.
Does anyone have any more information either on what Great Bridge's or Red Hat's versions of PosgreSQL have over the normal releases?
Perhaps you might want to look at the J2EE reference implementation, which is free. Right up front in the readme are the 3 supplied drivers - Oracle, Cloudscape and SQL Server v7.0. They've been there for a couple of years at least (1.2 release was middle-late 1999 IIRC). And, being a reference implementation, those drivers have to support the full specication - including XA transaction support. So, the drivers are hardly crap, maybe just not well optimised enough or that the underlying database is crap.
Life is complete only for brief intervals in between toys or projects -- John Dalton
By that logic Red Hat should be selling versions of Windows cos it's more popular.
MySQL has speed advantages in certain conditions, as does PostgreSQL, but Red Hat need features that enable them to compete.
--
Knowledge is, in every country, the surest basis of public happiness.
Err, like Mandrake did with Redhat's distro, except without the financial support?
I was under the impression (yesterday? 2 days ago?) that they would be starting a DB project from scratch. If what I'm saying is correct, why is this fucking steaming pile even being mentioned? All they are going to do is wrap a customized installer around someone else's hard work.
Earth to troll... This is what you're *supposed* to do with open source. Think, you can do the same thing with any of Redhat's GPL code, go ahead. Just give us something more than hot air.
--
Life's a bitch but somebody's gotta do it.
Yep. And why not call it "Redhat SQL Server?".
--
Life's a bitch but somebody's gotta do it.
Umm, there's nothing preventing them from selling it under the GPL.
A company I work for may end up selling GPL server software at a decently high price. Companies will pay it. They're used to paying for software.
Need a Python, C++, Unix, Linux develop
Hear Hear.
.. Q L". These were technical people, engineers and project managers, so I can't imagine trying to sell a customer on this, even if it did save them $5K over MS-SQL.
The branding point is really critical because, face it, PostgreSQL has really lousy name.
In a largely agnostic development shop, it seemed as if everyone had at least heard of MySQL and had certainly heard of RedHat, but were stumbling over "Post-Gres
"RedHat Database" (or "RHDB") might not be the greatest name either, but it's better than what they've got. (No offense to the Ingres, Post, and SQL people... Maybe change the name back to "Ingres" - some people remember it and it's easy to say)
--
Business. Numbers. Money. People. Computer World.
Just a note about the PHPBuilder.com article. Mysql has a problem with 30 concurrent users. This is a bit different than 30 users. 30 people can be connected at one time and mysql doesn't even sweat ... but when you get 30 concurrent queries, it starts to fall apart.
... if you get all your hits all within 6 hours think low end of the scale ... if it's pretty well spread out across the day, think high end of the scale). As most mysql users point out, mysql isn't meant to be used in super high load situations and this assessment backs that fact up.
For a pretty normal website, 30 concurrent connections can get you 500,000 - 1.5 million hits a day (depending on your traffic patterns
Now, I use mostly postgresql where I work (I need the transaction support and mysql didn't have it at the time). But I thought the current user point should be brought up.
Maybe for admin. But if you need a quick data entry form, or a quick report ("And please format it nicely, so it will look good. I'd like the company name to be bold, and a bit larger than the rest, and ..."), then a GUI tool is the only way to go.
That's the kind of thing that let Access keep it's market share before they bundled it into MSOffice, and they still had to buy FoxPro.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
I think that is mainly learning SQL. Did you leave off the smiley?
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
I'm sure hoping they put a bit of work into a RAD interface. Just Glade, Python, and some decent report writer would be great. For a first stab at the report writer, even an HTML generator would work. Even just this would be a real competitor to MS Access.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
I rarely use MySQL (and use PostgreSQL every day) but I thought the MySQL documentation was pretty good.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
that they should have gone with the inferior product because some day it may do what PostgreSQL does today. OK, whatever...
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
No, now they'll say sorry, never heard of it. But we can install Red Hat Database if you want!
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
RedHat and Oracle are not even on speaking terms.
Count the days down that RH 6.2 Enterprise stays on their website.
SuSE 7.1 was the primary Linux porting platform.
Anything from the 9.0 series will not be supported by Oracle Worldwide Support on RH Linux.
It is apparently an ugly falling out. Too bad.
But after the RH 7.0 release - I'd say that they get what they deserve.
Use SuSE.
.
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
Because both DB2 and Oracle are available on Linux, but perhaps you don't call them "decent"?
The DB-support on Linux is pretty decent.
MySQL is not a "better" database. It is a different kind of database. The design goals of MySQL are very different. MySQL is simple, direct, and very fast, but slow readers and updates are a very bad mix. For anything involving slow readers, look at a master-slave setup with the slow readers connecting to the slave, not the master. Benchmarks are pretty well useless since the results depend on the kind of load, not how good the databases are. Personally, I like MySQL, but you do have to code differently for it ("better" (IMNSHO)). Probably if any of the SELECT statements are outside of your control, you want something where slow readers do NOT block updates.
Not a huge suprise here since the original angel investor from Landmark who funded Red Hat is also the angel investor who funded Great Bridge.
In their own words. They're looking to do for databases what Red Hat did for Linux.
Given all of that, is it really any surprise?
http://www.bullnet.com
How to pronounce it: http://postgresql.planetmirror.com/postgresql.wavo cs/7.1/admin/history.html
- and -
Full background from the mid 80's to today: http://postgresql.planetmirror.com/users-lounge/d
>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
I'm sorry, but that is not the reason why Oracle does not allow third parties to perform and
publish benchmarks.
It is true that SQL Server performs well at the low end, but your implication that Oracle is
afraid of a comparison is wrong. Oracle *does* publish benchmarks, which can be directly compared
again the same SQL Server benchmarks. This is the reason why the TPC exists.
Oracle do not allow third parties to perform the benchmarks because they will not be fair, as the
required setup to get the best out of an Oracle database is quite complex. Also, Oracle have some
non-documented init.ora parameters which can be used to enhance the performance in the benchmark.
I worked for Oracle for 6 years. If you feel you have some better inside knowledge then me and
think that I am wrong, then state your reasons and your sources.
"The best part? I became an ordained minister while not wearing pants." -- CleverNickName
The current version of MySQL supports both atomic operations and transactions - transaction support depends on your table storage format... Please read the documentation (there are several sections on it...)
If MySQL AB reads the user comments in the manual, I'm betting that they will be implementing view and foreign key support soon.
As for a full SQL92 implementation, I think the only major issue remaining is nested SELECTs, right?
I print, therefore I am.
RedHat wants a DB. RedHat likes the GPL. There are good, GPL'd DB's available.
Where's the justification for reinventing the wheel?
I think the name 'Red Hat' is much more marketable and attractive than PosgreSQL. I too, seriously doubt that RH is thinking of forking the code.
PostgreSQL is PostgreSQL. If they don't intend to fork PostgreSQL, then why give it it's own name (Red Hat Database)? I'm not sure I understand the incentive here.
In the business world, what counts is service, support and reliability. RH is not selling software. They are selling service and expertise. PostgreSQL is a reliable but complex piece of software that requires knowledgeable people to support. That's where RH comes in. I am sure they have hired competent people who can help small to medium size businesses set up and operate their databases. Good move on RH part IMO.
ODBC, ADO, Oledb being de facto standards?!? Not in this world, they don't play even a tiny role. Only some client-side tools use ODBC via a JDBC-ODBC bridge, but such tools are highly discouraged (we rather generate CSV output from websites to push data into Excel, and don't want nor need ODBC. Writing back from a shaky product like Excel into a database of any importance is not allowed anyway). The only things that count are DB2 on the mainframe (with Corba interfaces) and JDBC databases on the rest (some DBI too for Perl). Since SQL Server doesn't provide good JDBC support (and 3rd party JDBC drivers for SQL Server are extremely expensive) it doesn't have a chance. Some smaller projects used SQL Server, but because of difficult integration they must be replaced everywhere (with Oracle, but Postgresql could also be an option).
Sorry Redhat but most IT manangers would choose MS in such a situation.
Right now, I doubt very much that Red Hat is aiming for or expects to get "most" IT managers buying their products. What thay _are_ aiming for is to get _more_ IT managers buying their products.
That is something which this development probably will do. I have very little doubt that RH will develop nice happy GUI interfaces etc for configuring RHDB, and that combined with Postgres not being crap, will result in more people using it.
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.
I don't see how anyone could have thought that they were going to start something from scratch. As for their choice of what to package, I believe it's excellent for all those involved, including those who will never use the redhad database system. Redhat will have more of a financial interest in postgresql, creating an environment where redhat will encourage the development of the product through widespread exposure and of course financial support as well as tech support for customers. Those who don't use the Red hat database system will still benefit from an improved and more thoroughly tested postgresql with a new infusion of money/developer power/user base.
My experience is that Watcom SQL/Sybase SQL Anywhere/Sybase Adaptive Server Anywhere/whatever they're calling it today is the most ANSI compliant database. After all, didn't PostgreSQL just get outer joins in 7.1?
Nonetheless, we're using PostgreSQL for our current effort because of the price and the quality. It also has an amazing collection of built-in functions, and its flexibility for implementing triggers/rules is superb, if a bit obscure on occasion.
All Your Base Are Belong To Us!!!
Guns don't kill people -- people kill people.
But the guns seem to help a bit. (apologies to Eddie Izzard)
For even more fun, take a look at the SAPDB sourcecode...
You're right. And those of us who played with, and were burned by, the immature Postgres have a permanently bad impression of it. I tried Postgres before MySQL because the license was more free. (A few years back). I found it slow and buggy. I also found that nearly everyone was using MySQL in the real world, so I got over the license and started using it. And loved it - it's a polished and really functional product, within its admittedly limited domain.
I played with Postgres again recently, and realized that because it (proudly) supports transactions and integrity constraints, I expect it to support a reasonable subset of SQL92. And yet, no subselects. And other annoying omissions I've forgotten.
Anyhow, what I want is a free Oracle-like database. I'm not sure how to even measure when Postgres gets there (although subselects are a necessity!) given the difficulty of benchmarking databases. Some say adabas is comparable to (pre 8i) Oracle. If so, I hope it catches on. To use it now would be to walk out on a very thin limb - I like the fact that all my Oracle and MySQL questions have been asked and answered on usenet.
So in the next generation of OS, Microsoft will do what best furthers their strategic interests. They have no need to balance this against market requirements, because realistically their customers have no choice. They will grumble about the loss of control over their data, etc, and pay through the nose for the same.
Free things will nibble the edges of the market while MS dominates the center.
You're right - I just tried a subselect and Postgres executed it happily. It was something else, something quite standard, that I was thinking of: I tried $thing and Postgres knew exactly what I meant, because it said "$thing not implemented". And for some reason I thought $thing == subselects.
So I tried strings `which postgres` | grep -i implement and I think it was ORDER BY and DISTINCT on views are not implemented which seemed such an arbitrary limitation. Admittedly a lot less important than subselects.
stepwise.com for osx related things (& osx server and openstep and ...). See the softrak section for osx databases (mysql an Pg both). nb: the osx server and osx sections are different; and I don't use either so ?? on the cross compatibility front.
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
This page is a prime example of the immense value they add. Sure, an admin out to keep on top of security mail lists and such, but how many of these programs even bother to keep security notices going back for 2.5 years? A list like (together with rpm -q) is extreemly valuable for doing a quick check to make sure you didn't miss obvious security holes.
PJRC: Electronic Projects, 8051 Microcontroller Tools
>I played with Postgres again recently, and
>realized that because it (proudly) supports
>transactions and integrity constraints, I expect
>it to support a reasonable subset of SQL92. And
>yet, no subselects. And other annoying omissions
>I've forgotten.
Maybe what you forgot to do is actually look at the feature list and/or try using the features you think are missing. Postgresql supported sub-selects even in the 6.X series.
Matt
* The threading vs. processes was indeed my bad. :)
Since I have no idea why I said one when I
meant the other.
* No, those numbers are meaningless unless more
background is given. What backend are they
using? What proportion of selects to inserts?
Are they simple or complex queries? How big
are the tables? What operating system and
hardware platform are they running on?
The "numbers speak for themselves" arguments
rank only below the "we lack all these features,
but you shouldn't use them anyways, and besides,
we're planning them in the next few major
release" arguments in sullying the reputation
of MySQL in a lot of people's eyes.
* Unless your website is publishing false
information, you're wrong about locking on
MyISAM tables. I quote, "Currently MySQL only
supports table locking for ISAM/MyISAM and HEAP
tables and page level locking for BDB tables."
* MVCC has been part of Postgresql since June
1999; InnoDB was originally interfaced with
MySQL September 2000 and made part of the
mainstream distribution March 2001.
Likewise, MVCC is the locking backend for EVERY
Postgres installation, whereas InnoDB likely
constitutes a small portion of MySQL installs.
Guess which one has proven itself in production
environments?
* Again with the "usually". Your statement is
meaningless and only serves to discredit your
repute if you don't give at least some context.
Yes, MySQL *can* be up to 100 times faster; it
can also curl up in a little ball and cry like
a little girl under loads that Postgres and
other more featureful databases would handle
gracefully.
No, not every database is suited for every
application, but as I pointed out in my
original comment, there are very few instances
I can see where MySQL makes a better choice.
The lack of a robust implementation of ANSI
SQL make anything but trivial database schema
painful to implement and typically requires
reimplementing the missing features in each and
every piece of client code. Though the latest
release of MySQL adds many missing features,
most of them are in table backends that are
not widely adopted and thus lack rigorous
testing (and I'm not talking about a simple
regression test).
The main complain is the lack of fine-grained
locking, which makes most common usage patterns
(save data warehousing, which someone was kind
enough to reminds me of) perform worse as
access grows. This very real limit on practical
scalability makes theoretical performance edge
nigh meaningless in many situations.
* If you'll re-read my comments on the benchmark
on the InnoDB site, the complaint about the
Postgres test was not that it was missing
instructions for recreating the results, but
that the ONLY comparison was on select speed,
single client.
However, my issue with the test against a
"market-leading database" was in fact a matter
of them using different methedology for testing
each database, and only publishing the perl
code for the InnoDB test:
"Source code of tests for InnoDB is included
at the end of this email. Note that the tests
were not run in exactly the same way for the
other database."
* Regardless of whether its hard to write
benchmarks that cover concurrent access or not,
it doesn't change the fact that what is
currently published on the MySQL website is
nothing more than marketing material. To recap
a previous analogy, its like choosing a sports
car over a pick-up truck for hauling on the
basis that the sports car goes REALLY fast
when carrying a single two by four.
* I've read innumerable comparisons between
Postgres and MySQL. Not to mention having a
fair amount of experience with both in a
production environment.
It was, in fact, my research and the limitations
and poor performance I have experienced with
MySQL in a large-scale deployment that have
formed my opinions on the matter.
Given that one of my "simple faults" was a slip
of the tongue and another is backed up by
published material on your own website,
coupled with your failure to adequately
address my "opinions", you might want to
reconsider the condescending tone you chose
to take in the first paragraph of your
response.
You could always do ORDER BY and DISTINCT *on* a view, just not as part of one.
That limitation is removed in the 7.1 release.
Matt
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
But - MySql has been plagued by the fact that they never implemented foreign key support into their DBMS.
Well, they know this as well. Please note the 1st item on the todo list for version 4.0.
The line must be drawn here. This far. No further.
Great Bridge and Red Hat are planning to bring new features and keep it's source closed for a while.
I do believe you need to back this statement up with some facts, if you've got them. If this is purely opinion, then please state what previous action RedHat has taken to lead you to this opinion.
The line must be drawn here. This far. No further.
Do yourself a favor - make the effort to move to Postgres
I probably would have already except for one factor. After a number of horridly failed attempts I've found a web hosting company that is both rock solid and with a fair price. The down side is that they don't do anything with Postgres as of yet. If it was offered up, I'd most likely jump on it.
As it is, MySQL has been doing a great job for me on a couple of different sites that I've put together. I've not had any corrupted data, downtime, or slow server response due to the database. One of the sites I've put together actually gets hit with a pretty fair amount of traffic, on a shared server even, and things hold up pretty darn well.
I may do some playing around with Postgres here on my local FreeBSD box before too long. Thing is, at this point I don't have a web host I really trust that I can publish that work to. The down side of finding a good thing in a hosting vendor is not wanting to jump around feature hunting.
The line must be drawn here. This far. No further.
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.
Will this become part of Red Hat Professional Server? I've heard a lot of good things about PostgreSQL and am very happy that Red Hat is going to start working with it! I use RHPS on a daily basis and will buy the next version even more quickly if Red Hat DB/Red Hat PostgreSQL will be included.
Very sweet news!!!
After adding all the above, MySQL will need some serious (read: light-years of) development on their query analyzer. MySQL does well on simple selects but performs notably slow on complex queries. Which is hardly a surprise given their assumptions, design goals, and evangelism.
InnoDB needs more testing, and it needs to continue to grow. I have full faith in Heikki Turri's skill.
I cannot say the same for the other MySQL AB developers. They have spent the last few years stonewalling efforts to turn MySQL into a real DB. They proclaimed that transactions were bad, table locks were as fine grained as you ever needed, constraints should be handled by the client application, and that stored procedures existed because other vendors couldn't write fast SQL parsers (thus showing a failure to understand the difference between declarative and procedural programming). Now, demands from their larger customers, plus products from people like Heikki, appear to be forcing MySQL AB forwards towards ACID compliance. So, no, I do not trust MySQL AB to implement these things quickly and effectively.
If you read their TODOs, you can see most of this stuff in targeted for 4.1. That's 2 major revs away. What will Postgres be doing in that time?
BTW, your web server is serving 403s. You should probably check on that.
The PostgreSQL Group has an mp3 and a wav on their site, has for quite a while now:
postgresql.mp3.
J
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
But then there's a huge difference. When M$ supplied Sybase with the kiss of death (nearly so) you as a customer had exactly two choices, provided you wanted to stick with the Sybase engine:
Buy Micr$oft SQLServer for a lot of money
Purchase Sybase SQLServer (Adaptive Server Enterprise as of today) for a helluva lot of money
Both database engines where quite comparable and both where propriatery.
This is the beauty of the Open Source model:
While Red Hat can fork it of course, or theoretically could even make a propriatery, binary version only, this is very unlikely to happen. And even if it would, it would probably be a failure and allienate a hell of a lot of key people.If Red Hat however develops cool features, those are very likely to wind up in the code if the Postgresql user community also deems them cool.
I think this announcement is a very good thing and will benefit all: Postgresql development, Red Hat software and the rest of us in need for an industrial strength, kick ass database engine.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
I dunno, it's hard to feel pathetic when your RDBMS knowledge boosts your salary by a few $10k per year.
Everyone here is seems to be under the impression that redhat isn't going to do anything but repackage postgres. I don't believe its true. Postgres already comes wiht redhat doesn't it?
I believe they are going to rewrite large portions of it and optimize it and probably even move some functions to a kernel level dameon just like tux. SQL server is killing the mid-level database level and its microsofts pawn to stela marketshare. Database is almost a requirement for any real bussiness app server. SQl server is taking the roll and including all proprietary tools like oldedb, ado, odbc, and a whole bunch of vb tools to take away any competion in the mid ranger server market.
We need a quick solution thats scalable fast, and cheaper. many of redhat's r&d helped make kernel 2.4 as fast as it is today. They will do the same wiht postgres. In 2 to 4 years it may be quite powerfull and competitive to SQL server today. I doubt it will approach Oracle though. If Tux is an indication of what redhat plans to do, then we will have one hell of a great database. My guess is it will be a different database then it is today in 4 years. Microsoft is going to strangle the market if we don't get our act together soon.
For the trolls who say post is postgres is postgres, is like saying linux is linux is linux. Version 1.2 of the kernel really sucked compare to what is capable in the 2.4 release. At the time 1.2 kernel users thought it was good enough and were convinced its great. Today we know its laughable. But I expect such similiar changes with postgres if RedHat is in charge of accerlating it.
http://saveie6.com/
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/
If I had any mod points right now I'd give them to wrinkledshirt. This is such an excellent point- red hat is a bridge for lots of people to get into linux, and they've done a good job not pissing anyone off too badly so far. Plus they are profitable.
So long as they don't abuse their brand by doing evil things, I say go red hat, build a brand so powerful that even the emperor himself will be forced to deal with us...
er,
if you'd just lead them to true freedom, they'd follow you, and so would I,
er,
bring balance to the force,
er...
I can't believe I'm not posting this anonymously
-one os to run them all, and in the darkness bind them...
microsoftword.mp3 - it doesn't care that they're not words...
I think you're mistaking supported drivers for included drivers. However, freetds_jdbc is good enough for use with BRL, even though a lot of advanced JDBC features are lacking. It's in production use where I work.
http://lwn.net/daily/rh-database.php3
To these kinds of people (which are unfortunately the people often writing the checks), when they hear PostGres, the name translates to a big fat "huh?". But if you take that software, gussy it up, and slap the word RedHat on it, and you instantly change that to "oh, RedHat's database".
I think its silly that such means must be gone to, but if this gets more opensource out into the enterprise world, then I'm all for it. Once people adopt the platform and the bumbling populace is more 'edumacated' about the Linux world, people will wake up and say "hey, I can just use PostGres!".
Damn the rusty wheels of corporate progress.
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...
Seriously, why not use sapdb? We know it's pretty robust, perhaps too much so? It seems like too good a product to just let it sit unused.
It probably has to due with branding and product recongition. If they sell it and make an effort to offer support for it, it has to have their name. As for why not Red Hat PostgreSQL, I think their marketing team probably just didn't think of it. It sounds awful, but I doubt that would stop a marketing team.
Even Slashdot wants to hide some things
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.
Who is more pathetic....the fool who talks about databases, or the fool who talks about talking about databases? (or the fool who talks about talking about talking about databases)?
After reading the story and other information in the past concerning this development, I don't understand what redhat is exactly trying to do here. Will redhat package the db on its on and sell the packaging + support? (like it does with linux) Why do this? Why not just increase distribution of PostgreSQL (i.e.: a download page on its site and add a couple of marketing dudes), add pay-for-support and put some caffeine drinking pizza eating coders on PostgreSQL? Seems as though RH is taking this too far. If they are going all the way, perhaps RH should use some stock to buy out one of the above mentioned PostgreSQL distros.
"There ought to be limits to freedom"
I am very happy to hear this. I write a database agnostic product and PostgreSQL is the only one that is consistantly ANSI compliant.
Red Hat probably wants to occupy the space that someone like Filemaker or maybe Foxpro would have previously occupied. Considering that Oracle and IBM have Linux implementations, that class of database stuff is already covered.
Postgres is usually included in most distros, but if Red Hat can manage to dress it up, perhaps slap a GUI on it, then they'll be cooking with gas, and definitely in a position to fool around with small, light load utility typw databases for non-mission critical and no heavy transactions (like Filemaker or Foxpro or even that abomination known as Access...)
The system has failed you, don't fail yourself. --Billy Bragg
I find this to be remarkably similar to what Microsoft did with Sybase and SQL Server. Eventually, you're likely to see RH with literally their own product such that it's unrecognizable as being postgres.
All I ask is that you look at what was said before labelling something as flamebait. You'll see that I said nothing even remotely critical of any company. I would recommend anyone curious doing a little research on the history behind SQL Server. It's quite interesting and merely shows two companies can have very different ideas of product direction without one of them being wrong. It's all a matter of focus and priorities.