Tuesday, February 12. 2008
PostgreSQL 8.3 is out
As many have said - PostgreSQL 8.3 was released on February 4th, 2008 and has numerous enhancements.
Listing of features can be found at PostgreSQL 8.3 release notes,
and has been mentioned ad-nauseum by several Postgres bloggers. Robert Treat has provided a nice round-up of blog entries
that demonstrate various 8.3 enhancements in his PostgreSQL Blog's 8.3 Feature Round-Up.
As a side note, the new EnterpriseDb funded Stack Builder feature for windows provides a nice complement for getting add-ons to PostgreSQL.
Horizon of PostgreSQL
Many PostgreSQL contributors are very proud of the fact that PostgreSQL is an open source
project and therefore can not be bought like MySQL which is an open source product made by a commercial company. I'm not sure general PostgreSQL users really care that much
about this. I suspect that many think
- yah - and Microsoft can be bought, Oracle can be bought, IBM can be bought - who is big enough to buy them and like they will kill off their prize cows
- and if Oracle, IBM or
Microsoft one day were to give away non-crippled versions of Oracle 11G, SQL Server 2008, DB2 to leverage their other holdings (perhaps slightly unrealistic),
what would that mean to PostgreSQL or MySQL?
- Can a community grow without money pumping into it and if it is not growing does it F*** matter that it is an open source project?
To many, the fact that PostgreSQL can't be bought and that its BSD licensed
leaves some nagging questions?
- What is the incentive for one to cooperate and not create an incompatible fork with lots of money behind it to make it better
than the main project?
In the end I think what most users care about are 3 things.
- Where is the project now? - things like what OSes does it support, if you are using shared hosting are their lots of hosters that provide it so you are not tied to one hoster, consulting support, training support, features, speed, ease of use, apps that can work with it etc.
- Where is the project going? - future growth of aforementioned items
- How fast is it getting there? - do I have to wait a year, 2 years, 3 years, my lifetime, in my dreams to see improvements I care about.
How high the project ranks in each of these areas is the most important and will drive users to support the project
and everything else is just debateable catalyst. When you think about PHP, .NET, Java, FireFox, Apache, do you even think about whether they can or can not be
bought. I know we don't much. The success of those tools I think demonstrates that the little guy, even if he knows little about IT really does matter. Microsoft realized that a long time ago, MySQL realized that, which is why they have been so successful. If it does what we need it to do, is easy to use, and doesn't cost an arm and a leg, that's how we pick our tools. Everything else is just philosophical snobbery. MySQL still
has an advantage in the hosting arena since pretty much any Linux host has it preinstalled. Its just there, low hanging fruit (aside from the confusing licensing), so just use it.
In the past, I think PostgreSQL ranked pretty poorly in these areas - e.g. it didn't work natively on Windows, had to compile yourself, wasn't available on many shared hosts (still is case, but the story is getting better), and it had some pretty
annoying user-friendly problems (it still does to some extent which we shall go into later, but is much better than when we started using it), and
it had extremely limited funding which slowed its movement. Because it had so few users and marketing behind it - it was basically a geek-only friend and therefore few used it and cared to fund it.
Today I would say PostgreSQL's pace of achievement is faster than any database (open source or commercial) and the more people relying on it for
mission critical applications, the faster that accelaration will become. That key fact faster acceleration, future growth is perhaps the number
one reason why we started to use it for projects where we had a choice of database over our past favorites. It may not do everything we need it to do today (heck none of the databases
we have come across do everything we need or would like them to do), but it is
getting there quicker than anything else.
Why is BSD License good for PostgreSQL?
I don't think the BSD license works for all projects, but for large commodity type projects such as PostgreSQL, I think it works well. The
reason: When you have a large complex project with lots of contributors, and is so bread and butter to everything that anybody does, its a pain to fork and then try to reintegrate
all the goodies other people have added in later versions especially if you are not in the DBMS building business. Its much easier to work right on the main path
so you know when you get back the new version - its got all your enhancements and everyone else's enhancements in it and no need to cut in your changes each and every time.
The BSD also means that if you choose to keep some piece of the pie for yourself (which is great for Integrators and DBMS builders) - you don't need to worry about the GPL police
coming after you. For small projects in niche markets with few updates - the incentive to fork is much higher.
Other incentive to cooperate
PostgreSQL is beginning to garner quite a few high-profile company/org use - Skype, Sun, Affilias, SourceForge, Sony Games, and Federal Governements to name a few
and these entities are not in the DBMS building business.
This means their incentive to pool thier money and invest in missing parts
of the PostgreSQL core, instead of handing over millions of licensing dollars to the likes of IBM, Microsoft, and Oracle is high. These companies provide a great marketing tool that no money can buy. The more features PostgreSQL piles on, the more of a no-brainer this decision is.
down to consulting service money, training support, ISP and Integrator support, confidence in users It is alive and building a whole ecosystem of applications that work with it, funding for missing parts and the whole thing just snowballs into a huge feedback loop
that grows with each new user as more people rely on this piece of software. The fact that it is BSD licensed is
attractive to businesses and research institutions alike. One can see this in the numerous side projects going on that
are built on top of the PostgreSQL core.
What is the deal with DBMS providers contributing?
As many have noticed, there are a couple of DBMS providers that contribute to the PostgreSQL group - e.g. GreenPlum BizGres,
and EnterpriseDB are perhaps two of the most glaring contributers. They build a DBMS that is not a forked version, but one
built ontop of the main core, but with added features. What is in it for them to contribute? Two thoughts come to mind for us
- The idea of a DBMS only company is non-existent. Even if you look at the likes of Oracle, IBM, and Microsoft SQL Server,
they have large consulting arms. Same case for EnterpriseDB and GreenPlum. In the case of EnterpriseDB and GreenPlum - I suspect their ratio
between consulting/support contract vs. selling of the product is even higher than the big commercial arms. This means they have
a vested interest in seeing PostgreSQL succeed.
- Even as a DBMS company - its always nice to take contributions from others and if a change you make affects the core,
its easier to keep this in the main path and keep some goodies for yourself on the side.
- Another prediction, as Open source software becomes more and more pervasive the ratio between consulting dollars vs.
money made from selling software will grow exponentially especially in high-end complex commodity products such as databases. This is
a drastic shift in the IT ecosystem.
What does PostgreSQL 8.4 and future versions have in store?
One of the great things about PostgreSQL, like many other Open source projects/products - is that you don't need to wait 3-5 years
to see changes and then have this gigantic thing that you need to engulf as you do with the likes of Microsoft, Oracle and IBM commercial databases. That is perhaps the most attractive thing about it.
Nevertheless, there are still some annoying facets about it today that make it more difficult to use in certain cases than Microsoft SQL Server or MySQL for example.
Hubert Lubaczewski had a similar rant a couple of months ago in What should be changed in PostgreSQL and while
we didn't agree with half the things he said and were on the Thank god PostgreSQL doesn't support that misfeature side, we do feel his pain in other areas.
Check out the PostgreSQL 8.4 wishlist for items that are on the brains of Postgres developers.
As Robert Treat pointed out in our PostgreSQL 8.3 is out and the Project Moves On, one of the features that was introduced in PostgreSQL 8.0 was the syntax of ALTER TABLE sometable ALTER COLUMN somecolumn TYPE new_data_type USING some_function_c
Tracked: Feb 12, 17:56