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."
I'm not sure what they have in mind here, but if that's the direction they're going it's clear why they wouldn't go with MySQL (technical shortcomings aside). PostgreSQL's BSD license makes it much more attractive for Sun, whose CDDL license is incompatible with the GPL, IIANM.
I might also suggest Firebird, the open-source version of Borland's InterBase product. It's licensed under a variant of the Mozilla Public License called the "InterBase Public License", but it doesn't seem too onerous. It's still a young product, but it looks like a good base, and I'm sure with a little spit and polish from Sun it could be a decent system.
There's also PostgreSQL's estranged mother, CA Ingres, the commercial version of Stonebreaker's original University Ingres. This is a well-vetted commercial-grade DBMS, although under another odd-wad license (the "Computer Associates Trusted Open Source License v1.1", see here).
That said, I would prefer to see them choose PostgreSQL.
Just junk food for thought...
Anyone know why they wouldn't use http://firebird.sourceforge.net/> ? I've used interbase in the past and I thought it was pretty damn good.
Since when did operating systems become a religion?
The same situation exists here. Sun is not legally bound to release any improvements back to the base, but can legally use any improvements that others provide to the base.That is what fragmentation is. One vendor chooses one path while a different chooses a different path.
Over time, the minor changes and improvements pile on until the two versions are not inter-changable anymore.
Yet each individual change/improvement/fix is insignificant and does not break compatibility.
We've seen this before and it happens again and again. It's always in the company's best interest to support the code base and the community
More like estranged cousin. The commercial version split off from the University version long before PostgresSQL.
> Have you conducted tests yourself or are you merely repeating fanboi retoric?
> I've used both views and subqueries with MySQL recently. stored procedures are
> listed for V5.
Views are listed as a new feature in 5 - which is just a development release. So, yes - the original poster was correct on that account.
MySQL picked up sqlqueries in V4.1, though I haven't checked to see how well they implemented them: ie, can you:
- select (select max(date) from a)
- select blah from table (select blah,blah,blah from a,b where...)
- select blah from a where a.blah in (select blah from b)
- select blah from a where a.blah in (select blah from b where b.foo = a.foo)
And can it perform these subselects without tanking performance? Especially given their poor quality optimizer and notorious performance problems with queries of 5+ tables...
So, given the massive gulf between just doing something and doing it well, and mysql's history of shooting for the bare minimum the actual usefulness of their stored procedures, views, and subqueries will take time to determine.
Over time ??? Since 1978 on the IBM S/38 ( aka, AS/400, aka iSeries, aka i5 ) the database ( db2/400 ) has been integrated into the operating system.
> 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.
If you'll excuse the shameless link, I've written up my thoughts in more detail here, and in the last /. post on the "SunDB" matter back in Feb, a bit of agreement was to be found on the Clustra theory. My disclaimer is, I suppose, that I've worked with and used Clustra, and live in hope Sun will see the sense of their purchase.
ooooooh! What does this button do? - DeeDee, Dexters Lab.
As a developer who works on databases a lot, I still find it very arcane when I do have to get right down and dirty and work on files again. It seems very primitive in a world of SELECTs and INNER JOINs.
I personally think every OS should ship with some sort of a light db engine equipped to handle databases stored in files. Imagine if you could write a simple application that opened databases just like you would with a db server, only using a file instead. When it comes time to scale it to a larger application, switch one line and connect it to a server instead. Or have your application configurable so that the user can either store it in a file or on a remote server simply by changing the server info from "c:\database.db" to "server:1234".
Indeed. The System/38 had this, and was way ahead of its time. I had one pretty much to myself in 1983-84.
Actually that's not remotely true.
Remotely true? It depends. High end is a logarithmic scale isn't it? And it's a moving target. I'd say the very idea of "High End" is only vaguely useful. If you need the fine grained control of the physical database Oracle gives you, then PG isn't high end enough. And it doesn't matter if a particular feature exists if it doesn't exist in the form you need it to. On the other hand, if PG does what you need, then you're better off without the cruft.
On top of this, it's a lot less painful to work with, and the SQL featureset is far nicer.
Agreed. As a developer I like PG better.
After having worked with them both on a daily basis, the only reason I'd willingly use Oracle is if I was working with terabytes of data and had lots and lots of money to throw at Oracle to make it work and support it
Which is my point, although it is probably not raw data volume, so much as having substantial data volume and having to manage it in a particular way. For example, I recently met some DBAs for a company that sells GIS data for a great deal of the world -- most of the developed world in any case. Maintaining this data is more complex than you can possibly imagine, unless you've actually seen it being done. On some of their tables, storing, maintianing and updating a single spatial index could be a bigger job than 99% of the complete database applications there are, and that's not even necessarily the main challgenge. Even talking about a single country, or state/province, it's managing the work flow, the locking, the publishing, the versioning of the data that means Postgres' spatial database capabilities aren't even remotely close to what they need.
PG's GIS capabilities are about 90% of the way there for me but I'm a different story.
I don't want to blow too much street cred here, so let me say: I thing Postgres is great and getting better. I find dealing with the Oracle way of doing things like giving myself a deliberate paper cut. I despise Oracle as a company and think Ellison's a vile and pompous blowhard who's probably compensating for anxiety over a shortcoming in some department or other. But I mean that in a nice way.
But, I think the "Postgres Rocks" or the "SQL Server Sucks" way of looking at things is more entertaining than enlightening. SQL Server may be the right choice for a project. The reasons may be political or marketing rather than technical, but so be it. We don't live in a world where the ultimate success of a project is completely isolated from these factors.
I happen to dislike a lot of the same things about Oracle you apparently do. But my technical likes and dislikes aren't of overriding importance, and my political likes and dislikes don't matter at all unless they rise the level of right and wrong. When I point out that Oracle has certain features that PG lacks and will continue to lack for a long time, I'm not saying Oracle is the One True Database and PG is Just a Toy, or that Postgres Isn't Ready for the Enterprise (whatever that means). I'm just saying people pay a lot of money on high end iron for things Oracle can do, that by in large products like PG aren't even close to yet, not because they are stupid (some of them may be).
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
> I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability
:-)
that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000. A perfect example was stored procedures - where you couldn't return a result list in postgresql, and the python stored procedure language required so many ticks and escapes it was impossible to use.
Regarding oracle, it used to be so much worse than it is today. For small databases it really doesn't take much time at all IF you are familiar with the product. If not, then you need to hit the books for a little bit. And the price isn't hefty at all - it can be cheaper than your redhat license for small databases. The much larger databases is where the cost is really at, but postgresql doesn't compete there anyway. In the middle ground - that's where you've got decisions to make - and the cost could go either direction, depending on how you architect the solution & negotiate.
Regarding yukon - the informal benchmarks i've seen indicate that it isn't going to provide anything for performance. Another major drawback with SQLServer is the entire gui orientation: it's great for demos and development databases, but if you've ever had to migrate code (such as for DTS) from test to production by recreating then you know what i'm talking about.
I'd also consider db2 & informix: together have a huge chunk of the market and are gradually merging together. The licensing is about 1/2 that of oracle, with about 98% of the functionality. Plus they'll handle more data. On the downside there are considerably fewer admin tools for db2 than oracle, and fewer talented developers or dbas as well. Ah, and perhaps the biggest issue: there's no Larry Ellison involved.