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."

Comments

Predictable

[AKAImBatman]

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.

Re:Predictable

[hey!]

PostGreSQL has none of these issues, and can hold its own in a comparison with Oracle or SQL Server.

Depends, you can't exactly put a product like a RDBMS on a single scale. But in general it makes some sense to compare Postgres to SQL Server, but very little sense to compare either of those products with Oracle; although the limited attention span of most "decision makers" means that in practice the marketing departments of MS and Oracle play that game.

Oracle really really wants people to use Oracle for everything, and in truth you can use it for a lot of day to day database tasks, in the way you could use an eighteen wheeler to take your kids to soccer practice. Oracle's not very standards compatible. There's a million ways it traps you into their product. There's endless ways to shoot yourself in the foot, and getting things back requires a kind of black sorcery. In short, Oracle really sucks, unless it's the only tool that can do the job; in which case it's wonderful. Oracle's built so you can perform heart surgery on the patient while he's running a marathon, for the kind of applications where serious money is lost every time the database hiccups; the kind of applications where you have a team of DBAs who are paid six figures and it's a bargain.

SQL Server, to my mind, is mediocre. It's the choice of the departments who believe thing are easier if everthing comes from one vendor, and it's good enough to keep them out of too much trouble much of the time. From a DBA's standpoint I'd guess it's very easy to administer up to the point it becomes useless; if you never get there, you're happy. From a app develper's standpoint, it's pretty dreadful, but these days the style is to put as much as you can in the app tier so that doesn't matter much as it used to.

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.

Re:PostgreSQL vs MySQL

[Cmdr-Absurd]

Yes. They have been compared.
A quite legnthly comparison can be found here.
SQL92 compliant is a relative term.

PostgreSQL vs MSSQL vs Oracle

[WebCowboy]

...is probably the most fair comparison.

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 .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.

Re:Hmmm.

[kpharmer]

> Actually that's not remotely true. We're not talking about MySQL here.
> PostgreSQL is quickly gaining all the "high-end" features of Oracle:
> tablespaces, failover, replication, etc. In some cases, they aren't yet as
> fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly
> coming into its own.

Hmmm, as much as I like postgresql I don't see it that way:

1. replication? it's most often used as a clunky way of implementing failover - yuck. In my large data architectures, replication is almost never used: it's almost always the worst solution to some problem.

2. tablespaces? yep, they're good things to have. that's fine - i think oracle and db2 have supported them for around twenty years, so it's hardly high-end technology tho.

3. failover? ok, this is critical - but there are also many different forms & flavors. I'm not familiar with what postgresql has so I won't comment - other than to say it needs to be rock-solid.

ok, how about a few more:

4. memory management: a high-end database should give you a ton of control over how memory is handled - especially when you plan to buy tons of it. Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces. These bufferpools (caches) are how to easily ensure that hits against some tables or indexes occur 99% of the time from memory, and others 50% because they're so much larger. I'm pretty sure that neither postgresql or mysql can do this.

5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.

6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.

7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to. So, while db2 or oracle are scanning 10% of the data - postgresql or mysql still have to scan 100% of the data. That would result in a 10x increase in speed over postgresql or mysql.

that's just off the top of my head - given a little time this list would double.

Postgresql is a fine tool, and it has all the technology that db2 or oracle had 12-15 years ago. And that's a cool achievement, and qualifies it do a ton of cool projects. Plus, with time it will catch up. But it still has a *long* way to go.