Slashdot Mirror
Sun Eyes PostgreSQL
Da Massive writes "Sun is looking seriously into the database market - namely PostgreSQL. It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter.
This from John Loiacono, executive vice president of software: "We're not going to OEM Microsoft but we are looking at PostgreSQL right now," he said, adding that over time the database will become integrated into the operating system."
It says Oracle and IBM and even Microsoft licensing fees are way too expensive for the average punter.
An NFL punter usually makes between $250k to $1M a year. They can handle most DB costs...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
This really isn't a surprise. MySQL has both licensing problems, and feature problems in the competitive high-end markets. PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server. These features led RedHat to PostgreSQL for their RedHat Database product, and I see little reason why they wouldn't attract Sun as well.
The only thing that slightly bothers me about their strategy is that Sun has been pushing their Java Systems hard. If they actually wanted to bolster that strategy, they'd have three major options for a Java Enterprise Database:
1. Cloudscape/Derby - This product makes the most sense from a technology and licensing perspective, but the fact that it was an IBM product (even though Cloudscape was originally a separate entity before being acquired) taints the software in such a way as to make Sun look bad if they used it.
2. Daffodil - This database is an excellent choice, but it would require the acquisition of another company, a move that the Sun shareholders might question. It would also bring quite a bit of flak in Sun's direction as Daffodil is an Indian company.
3. McKoi SQL - An excellent choice for a Java database, but lacks brand recognition. The feature levels and scalability of the database are still considerable questions. The GPL license also allows Sun less freedom to modify the database in comparison to the BSD license used by PostgreSQL.
As for the choice of Sunbird, I think it's simply a matter of "why not?" It's not like there's any particular leader in the market, and Sunbird plays nice with Firebird/Mozilla.
Javascript + Nintendo DSi = DSiCade
Sun gets to use repackage PostgreSQL however they like, more people will be using PostgreSQL and finding bugs and adding features and writing utilities, more books will be sold, more consulting opportunities - everyone wins.
I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part. And the products that are based on PMD? Just means more books sold. Good times!
The Army reading list
it's clear why they wouldn't go with MySQL (technical shortcomings aside).
Actually, I'd say that the technical shortcomings have a LOT to do with it. PostgreSQL can be placed head to head with Oracle and still pretty darn appealing. MySQL really don't have that capacity (yet), and is hampered by its non-ANSI comaptible design and SQL variant. So I'm not certain that the decision was made entirely on licensing alone. After all, Sun does support the GNOME project as well, and that is solidly under the GPL.
Javascript + Nintendo DSi = DSiCade
On top of being closer to the standards Oracle uses, IIRC, PostgreSQL uses a transaction model that is essentially identical to Oracle's, even though it's implemented differently. In spite of the hype around database independence, the reality is that the differences in transactional behavior radically affect the ability to port from one database to another. The fact that PostgreSQL's native stored proc language already looks a lot like Oracle's PL/SQL, with an effort to make PostgreSQL run PL/SQL unmodified in the works elsewhere, is another big plus.
Well, they don't have to give anything back, if postgres is BSD-license. But in practice, they probably will. Not everything, but quite a bit. It's in their interests to give back to the community a lot of the changes they've made, so that the work done on the free version doesn't unnecessarily duplicate the proprietary version, and so that the next release of postgres doesn't force Sun to rewrite half their modifications. Basically, if Sun want to take advantage of progress made by the community on postgres, then they'll be giving back some of their own. They don't want to diverge too far.
Real Daleks don't climb stairs - they level the building.
SQL92:
PostgreSQL > MySQL; but MySQL is improving it's feature set
SQL3:
PostgreSQL > MySQL; PostgreSQL has a few SQL3 features
Speed:
PostgreSQL ~= MySQL; sometimes faster, sometimes not
Database\table\row\... Size:
PostgreSQL > MySQL; PostgreSQL has less size restrictions, or at least, the limits are much larger than those of MySQL
Stored Procedures:
PostgreSQL > MySQL; MySQL not yet, but in 5 they have SQL:2003 like stored procedures; PostgreSQL has SQL, C, pgSQL, Tcl, Perl, Python and roll-your-own and a few not bundled with PostgreSQL
Installation\maintenance:
MySQL > PostgreSQL; MySQL is easier to set up
OS Support:
PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version.
Yes. They have been compared.
A quite legnthly comparison can be found here.
SQL92 compliant is a relative term.
> PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version
;)
Yes indeed, now if only there were a stable Windows platfrom on which to run it.
Unlike all the articles about linux and it's rise as an OS, Open Source databases do not have the same major difficulty. With an OS, every user that uses the computer has to know how to use the system. Conversely, with a database, most, if not all users will not care what database they are using. For example, for my job, I write and maintain a windows application that supports 3 different database back ends. Our clients can care less what database they are using. Only IT and whoever is in charge of the cash will probably care what database is running. In my experiance, IT will not really care what they use because DB issues don't usually take up the bulk of their time. As for whoever is shelling out the money, well that is a toss up, but the trend that I see is that more companies are opting for less expensive DB options.
Again, open source DBs have a chance because not every user works with them directly. Also, the interface, SQL, is a much more standardized interface than with an OS. As a programmmer, writing queries to DB A is pretty darnd exactly like writing queries for DB B. So, I think that their will be much better competition in the database world as in the OS world.
I wonder if it would create any confusion if Sun started marketing Mozilla's Sunbird. It'd be nice to seem some fresh development on that project though.
> Installation\maintenance:
> MySQL > PostgreSQL; MySQL is easier to set up
PS, this doesn't hold up on Debian systems:
apt-get install mysql-server
vs
apt-get install postgresql
the latter is less typing.
I've had people contribute code to PMD and say they were only contributing it because they felt the BSD license avoided any possible obligations on their part.
Just like there's plenty of people who only contribute to GPL projects since they don't want "evil corporations" stealing their code.
You can find fanatics driven by ideology rather than common sense in both camps. That's hardly something to cheer about.
Sun gained an excellent database when they acquired Clustra. What happened to it and why are they now talking about Postgres? Are they really that intent on pissing away that investment?
True, on the surface. However, if they don't then the next time someone modifies that bit of code, then they will have to re-merge their changes. If someone else fixes the bug in a different way, they have to do code review on both implementations and then decide what they want to keep.
There is a reason people like Apple contribute to BSD projects - it's cheaper to get your patches merged upstream than to maintain a fork.
I am TheRaven on Soylent News
The article seems a bit heavy on posturing and light on details, almost like it's there to get the message across: fear Microsoft because it competes with its customers.
Otherwise, it seems a bit curious to me, because it juxtaposes two things that don't seem to go together in my mind: High end database management and penny pinching. Prices for Oracle on low end hardware (x86 servers) are not high at all, certainly not high enough warrant any concern at all in any project that doesn't get staff and DBA time free. Once you pay for a couple of professional staff the Oracle license fees are not worth worrying about, if they are even a bit more productive. Prices for Oracle on big iron are shocking to people whose idea of a big software procurement is a couple of dozen boxes of MS Office, but in those environments they are likewise not out of place.
Oracle's licensing model is incredibly byzantine. It takes days of study to get your brain around it. Once you do, what's obvious is that it is a reflection of the company itself: it's a complex machine designed to squeeze every last marginal dollar out of the customer. But -- the reason it works is that the prics are very carefully calibrated so you don't really save any money by going to the competitor. For example, if you just grab the biggest license you can on the x86 platform to make your life simpler, you will pay dearly. But if you are selective and understand the model resaonably well, Oracle is about the same or perhaps even cheaper than SQL Server on equivalent machines. Of course if you don't know what you're doing you'll be accidentally sending Oracle beaucoup bucks, like CA did a few years ago. I assume midrange and high end licensing for Oracle are the same: they maximize Oracle's revenue for the specific capabilities you license from them, and it behooves you to choose wisely.
Of course, no pricing model works for everyone. Perhaps there are people on high end hardware who just need something that is very fast and very reliable, not highly configurably fast and as reliable as human ingenuity can make it. Which leads me to a conclusion:
Talking about Postgres in the context of Oracle and DB2 is probably just posturing. It would be years, if ever, before Postgres gets the kind of features that make Oracle a must have for many high end applications. So I'm guessing this is really aimed at delaying the encroachment x86/Windows/SQL Server on the midrange, by giving a big vendor seal of approval to Postgres, which is plenty good for the kinds of apps you run on SQL Server, and quite a bit better if the hardware is better.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
> Someone I know is working with an MS SQL Server database that's too slow to be usable
Not true, sql server is a fine database. Its problems have more to do with being excessively gui-driven, expensive compared to OS dbms, and owned by microsoft than anything about the speed.
> and I'm wondering whether I should suggest they go with PostgreSQL instead
not having benchmarked them, i would guess that sql server would be faster on the same hardware.
> Do you still need to VACUUM your databases?
I think an automated vaccuum has been created. But it was never a real issue in my opinion anyway - basically the existance of vacuum enables postgresql to speed deletions and updates - since some table maintenance can be performed asynchronously. So, cron (or task schedule) the thing to run nightly and you're fine.
> Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)?
Not yet, but it's getting there. 5.0 should be a big improvement, but it still has a long way to go - not necessarily implementing the essential feature set, but now making those implementations robust.
> How does Oracle's performance compare to the rest?
Depends on what you need to do: have a small database, or a medium-sized database that's purely transactional? The open source databases can do the job. But if you've got a large database, or want to do some analytics (like show simple trends of data) then oracle/db2/informix are your friend. These commercial databases can easily be 40x the speed of postgresql or mysql on the same hardware for analytical queries.
...is probably the most fair comparison.
.NET--meaning that you can write stored procs and functions in any .NET language. So, they are probably a pretty close match except in a couple of areas--PGSQL is free (libre and gratis), and PGSQL is not platform dependent. I think that the fact MSSQL only works on Windows is a major drawback when all its competitors offer products that run on Windows, Linux and various UNIX derivatives. Various "facts" notwithstanding I still think that Windows servers are a greater administrative burden and more difficult to secure than other alternatives--perhaps the next server version after 2003 will have addressed that.
Don't know much about Postgres in production environemnts. It seems clean and I like the fact you have a choice of stored procedure languages.
I have had experience with both in production environments, and I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability. It is much better than MSSQL with concurrency and managing contention (MSSQL's locking strategy is quite brain dead). There is much more flexibility and power to create user functions and stored procs in PGSQL--you can do things like make user-defined AGGREGATE functions and data types in addition to having a choice of languages (none of that is possible with MSSQL). I find that all things being equal PostgreSQL is probably faster as well (largely an assumption becasue the PostgreSQL systems I've worked with are running on considerably less powerful hardware than the MSSQL systems I am doing). A lot of people comment about the ease of administration of MSSQL but I find that PGSQL really isn't that hard to manage even if you don't use GUI tools.
Oracle is certainly one step above PGSQL in power--but of course that comes with a very hefty price tag. That price isn't just in licensing either--Oracle takes more time to administer and you also pay by losing flexibility, since enterprise systems based on Oracle better do things the "Oracle way" or you are inviting trouble (just like with Microsoft products, Oracle really pushes its single-vendor solutions).
I have not played with Yukon/MSSQL 2005 yet, though I've heard a fair bit about it. From what I've heard it closes the gap a fair bit and comes much closer to PGSQL in terms of features and performance--it is supposed to handle locking/contention better and its has embraced
Thank goodness for SQLite, then. Just add the dll (or dependancy for linux-folks) to your package and voila. This also assumes you're using some DB-abstraction layer, such as PDO, ADO, ADO.Net, etc...
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
The biggest one that has made a difference in my life lately:
Table Partitioning:
PostgreSQL > MySQL; Mainline PostgreSQL has table partitioning as of 8.1-beta, by leveraging inheritance (Postgres is an Object-Relational Database).
Queries on the aggregate of the partitions are directed at the parent table, and optimized to only look into appropriate sub-table by checking CHECK constraints of the sub-table against the query WHERE clause.
Basically, you do it like this (contrived, but related to how I'm using them at the moment):
MyBigFatTable stores timestamped data from a bunch of a machines at regular intervals, keying off of the machine id and the timestamp of the data:
CREATE TABLE MyBigFatTable (
machineid INTEGER REFERENCES machines(machineid),
stamp TIMESTAMP,
data_x FLOAT,
data_y FLOAT,
[... lots more data fields
PRIMARY KEY (machineid, stamp)
);
Your problem is, the table size grows and grows and grows unbounded, and database operations continue to get slower and slower (inserts, updates, and selects) as the table grows. You have a policy to expire the data after a month which limits the maximum growth, but this in turn requires lots of deletes happening all the time, which again hurts performance.
The inheritance-based partitioning solution is to leave that table definition as it is, and also define:
CREATE TABLE MyBigFatTable-2005-10-05 (
PRIMARY KEY (machineid, stamp),
FOREIGN KEY (machineid) REFERENCES machines(machineid),
CHECK ( stamp >= '2005-10-05 00:00' AND stamp '2005-10-06 00:00')
) INHERITS MyBigFatTable;
As you can see, the column definitions are inherited, but you must re-specify the PK/FK stuff. The added check clause says that only data from Oct 10, 2005 is valid in this subtable.
You set up a maintenance script to create your new time-based tables ahead of time (say once a day create tables for the next day), and you do your data INSERTs into the specific subtable (you know the timestamp of the data you're inserting, so you can generate the appropriate table name from that (MyBigFatTable-2005-10-05).
You run your SELECTs against the original MyBigFatTable just as you did before. It automatically includes any rows from its child tables. Further, if your SELECT's WHERE-clause was constraining a query to a specific time-range, only those children of MyBigFatTable whose CHECK constraint indicates they could possibly have relevant data are checked.
And as for the problem of expiring data and the delete traffic you had before? You simply drop the old child tables with "DROP TABLE" from a maintenance script when they're a month old - no DELETEs neccesary.
11*43+456^2