EnterpriseDB, the open source database company, aims to capitalize on the uncertainty around MySQL's purchase by Sun Microsystems, and is wooing developers with improved capabilities and services. According to chief executive Andy Astor, revenue has quadrupled in a year. But when it comes to developer uptake, PostgreSQL the open …
Why do we bother anymore
It's all getting a little corporate. Everytime we select open source - we do so primarily two fronts - priciple & performance. Sun's purchase suggest that within 2 years MySQL will be unusable, sluggish and who would work with such a struggling fuck*dompany.com. Sun is s a company that lacks principles. I've spent years providing code updates and suggestions to many - jBoss, MySQL, Ingres - to name a few. Each time some behemoth steps in and makes wealthy men out of previously principled CEOs. The little guy always loses out. I may end up just buying a SQL-Server 2008 license - when it's released - 2011.
It's all too depressing
Best o' luck to EntrepriseDB/postgresql
I've completed the switch of my own app from MySQL to postgresql. Mostly because I've learned not to trust MySQL's support for complex non-select queries.
Postgresql seems comparatively a much more mature, staid, database that does what it commits to do reliably. The documentation is quite good as well. I've been coding complex SQL for about 15 yrs and postgresql just feels more capable overall, not just a CRUD engine.
I can see it as a credible alternative to buying a proprietary database. Especially if you hedge your bet by using it in a way that remains Oracle-compatible. Face it, at the end of the day, if your requirements end up going through the roof, you can't beat Oracle performance (except on $$price$$, of course). And, no, SQL portability isn't that big a problem, if you know what to watch for.
To try and bring back the faith can I remind you that Postgres is of a different model. It is about the database not the company, whereas MySQL was more about the company rather than the database. This is evident in where it used it's resources, which may have benefited the developer in the quick term, however any serious db enthusiast realised it's shortcomings. I use PostgreSQL extensively in all my projects, and have never needed to visit these EnterpriseDB guys, however if they are helping develop the product then that is good. But remember PostgreSQL's heart remains at www.postgresql.org, and so I find it hard to believe that Postgres could suffer the same fate, be it for better or worse, as MySQL.
Hoping that next time you will choose a non company centric open source product to contribute to.
Can't beat Oracle
I beg to differ. Sybase and DB2 are, in my opinion, superior products. Of course they're not Open Source.
It's true that at the high end MySQL can't compete with them but it's also true that a lot of people don't need that kind of high end performance or some of the more sophisticated Replication offered by Sybase.
One final point: Following this article I will re-evaluate my use of MySQL and see if it makes more sense to use Postgress.
"...if they are helping develop the product then that is good"
My understanding is that enhancements go into EnterpriseDB's own proprietized version of PostgreSQL. They are providing PostgreSQL support because uptake of their licensed product was poor.
The "revamp" involved sacking sales guys, seeing other key developers leave, and management taking on business development.
I predict that, despite bullish statements about their performance, their lack of strategic direction and Sun's acquisition of MySQL (they have been using EnterpriseDB to subcontract PostgreSQL support to) will eventually see the VC guys getting cold feet.
Postgres v MySQL - An alternative
If you really want to replace the low end web-database MySQL, consider SQLite (www.sqlite.org):-
"SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than a 100000 hits/day should work fine with SQLite. The 100000 hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic."
The SQLite licence is much friendlier than MySQL. Applications using SQLite can generally be upgraded quite easily to Postgres or Oracle - Anything that you are likely to produce in MySQL, will tend to remain stuck in MySQL.
Oh!, and unlike SQL Server, SQLite will run on almost any OS.
It all depends on your project but having moved to PostgreSQL a few years ago I've never looked back. I always shudder when I have to work with MySQL (MyASM) when slight differences in queries have massive performance differences and where anything but the most basic relations become very sluggish, unreliably enforced constraints, etc. Even if I'm not allowed to use PostgreSQL for a project I usually take the time to do a test import to check data integrity.
In that time PostgreSQL development has really come on a lot: native windows client, improved scalability and the upcoming inclusion of the full-text search functions. MySQL's strengths were largely based on understanding how to pander to the web world and realising native windows code and GUIs in much the same way PHP and Java, of course, did. Lowering the technical barrier of entry does mean that more people will try your stuff. Whether or not we understand what we're doing is another matter.
For embedded work such as storing application preferences SQLite is okay but it does suffer heavily in a multi-user environment because of file-locking.
Yes, I agree that SQLite is not suitable for multi-user Client/Server applications because of locking issues, but it is fine for a simple web site where you have essentially one client (The web application.).
A relatively small numbers of concurrent users can be served with the EXCLUSIVE, SHARED and PENDING locks in SQLite Version 3+, but the authors caution against use of network file systems. You can however write applications that rely on you being able flush data to a single disk by a remote client accessing a particular server process, this allows multiple applications to access the same database at the same time.
However, as you say, for a traditional Client/Server system you need to use a Server Database. There is a beta version of server type product SQLiteDBMS (sqlitedbms.sourceforge.net), but not much seems to have happened with it for a year or so. Or there is a commercial product that is very similar to SQLite from realsoftware.com, but that costs real money and seems to be for 10-50+ concurrent users. Postgres works for me, as most triggers etc. export fairly easily from SQLite...
RE: Strategic Confusion
To the anonymous coward who says that the improvements that EnterpriseDB makes stay in the proprietary product, take a look at the release notes for the latest release of PostgreSQL. Looks like almost 50% of the BIG feature enhancements for PostgreSQL are contributed by EnterpriseDB folks.
Didn't seem to me like the uptake of the proprietary product is doing just fine and that the PostgreSQL support was just a natural extension since they have so many PostgreSQL folks onboard.
BSD versus GPL
A key difference from mysql is that postgres is totally free source software which you can combine into your own non-open source product and sell/pass off as your own if you like. This broadens the base of companies that can use it to anyone whereas mysql is limited to those who can either sell their software under gpl like open source or pay the mysql fee to use and distribute it without source. Apache benefits from the same freedom.
- +Analysis Microsoft: We're making ONE TRUE WINDOWS to rule us all
- Climate: 'An excuse for tax hikes', scientists 'don't know what they're talking about'
- Apple: We'll unleash OS X Yosemite beta on the MASSES July 24
- Yorkshire cops fail to grasp principle behind BT Fon Wi-Fi network
- White? Male? You work in tech? Let us guess ... Twitter? We KNEW it!