EnterpriseDB is trying to pump up the PostgreSQL database to do battle with Oracle 11g and, to a lesser extent, IBM's DB2 and Microsoft's SQL. So the database upstart is upgrading its Postgres Plus Advanced Server 9.1 - and kicking it onto Amazon's EC2 compute cloud to peddle it alongside Amazon's own Relational Database Service …
You have alienated one of your most loyal partner, reseller and system integrator so much they now promote a competing product. A product which is essentially as free as Linux and something even wealthy customers such as major stock exchanges will soon adopt as a replacement for your pricey Oracle RDBMS.
My personal experience with Postgres as a developer is very good, so it can be expected to gain a considerable number of users in the next few years. You, Larry, will certainly find many ways to screw up MySQL and that will mean people will move to Postgres in masses.
RE: Thanks, Larry
"....even wealthy customers such as major stock exchanges will soon adopt as a replacement for your pricey Oracle RDBMS...." Well, yes and no. There are a lot of smaller Oracle DB instances that can be ripped out and replaced by Postgres (and some nice docs on the hp webby on how to do it), but in the high-end there is still the issue of scale, which Oracle simply does better at the moment.
@"Postgres does not scale sufficiently"
I do think plenty of DB users are now capable of using a more "googly" database architecture, which means partitioning a database on the application level.
For example, an airline reservation system could be split into 50 physical servers, with each handling 1/50 of the airline's aircraft. It is not horribly difficult to do that, if an application is designed to do that from the beginning.
All what is required is a little more education and work by the application developers. And certainly an open mind, something which is of course in short supply in many operations...
Try using an example about which you actually know something.
Maybe my wording was not accurate, I meant "aircraft boarding/seat reservation system". Tell me why my approach can't work.
Also, tell me why this design pattern cannot be applied to scores of other business problems such as manufacturing cars, telecommunications, government financial systems and so on.
This always seemed the obvious downside to Oracle buying Sun. As a standalone RDBMS vendor, they had the strategic weakness: you'd have to use it alongside an OS from IBM, HP/DEC/Compaq, Sun, Microsoft or some form of Linux. In almost every case they'd be going up against an RDBMS with "home field advantage" - I remember specific API changes slipped into a Windows 2000 Service Pack to boost SQL Server's performance at the time, for example, no doubt each platform has more recent equivalents - so I'm sure the Sun/IBM sales guy would have kept slipping into conversation "yes, we'd be happy to stick in an extra 128 Gb of RAM to make Oracle keep up ... did I mention we've got a special price on $OTHER_DBMS?"
I've always been impressed - or depressed - by the effectiveness of Oracle's brand-marketing to non-technical management types; I once spent at least an hour explaining why actually, Oracle *wouldn't* be the best way to store the 100k of text we had in an XML file. It was really important data, y'see, so surely it needed really Enterprisey(TM) storage around it...
Oracle System Diversity Was A Strength
I disagree with the first part of your analysis. Oracle grew big by having their RDBMS running on nearly every computer except Atari, Amiga and C64. This is quite similar to the success of Intel, Microsoft and Seagate, who all specialized on a part of a computer system, as opposed to the "vertical integration" of IBM, DEC, Unisys and HP.
IBM is gradually un-becoming a hardware and systems company, while Intel, MS, Nvidia, Seagate and so on are stronger than ever. Mr Larry simply made the wrong turn by buying SUN. It probably was the fulfillment of his dreams, but not of his rational thought.