Once Oracle bought MySQL, I saw a lot of the anti-MySQL comments in the PostgreSQL community die off pretty fast. The types of comments changed as well. Instead of the message that "we are much better technically than MySQL" (which is still hands-down true btw), the message was "if anyone asks, PostgreSQL cannot be acquired because there is no commercial entity to acquire." The shift was very much to let concern for Oracle start the conversation and simply explain why this cannot happen with PostgreSQL.
The very basic point is that anything PostgreSQL users can say here is redundant and really only belongs when answering people's concerns about the future. "Can this happen to PostgreSQL?" gets asked and most of us wait for that question before saying "no."
>MySQL and PostgreSQL represent two very different implementation philosophies, and being able to choose between them according to taste and merits is a good thing.
I guess you could say that. I would sum it up as "PostgreSQL is what you get when database hackers set about building a database to explore new concepts in. MySQL is what you get when you get application hackers building a bottom tier for their applications." MySQL's paradigm is fatally app-centric, however and I have a hard time seeing that as a good thing. I'd be happier if the app-centric db chosen was SQLite or Firebird DB.
The other thing to keep in mind is that MySQL really has been becoming less interesting as a competitor over time, and the Oracle acquisition has helped that along as well. Really, there's no point to bringing up PostgreSQL at this point. It just feels tasteless, like a victory dance on someone's grave (premature to be exactly equivalent but you get the picture). I'd rather see PostgreSQL targetting MS SQL and Oracle than MySQL. There is no honor in beating the weak. If we are going to go after someone might as well pick the strong :-D
Hence, sensational and petulant "RIP $PRODUCTNAME" articles are unnecessary. There is no threat to existing projects based on MySQL or any other successful open source project for that matter. Not only will this stuff be free forever, it will also continue to grow and be developed on its own.
Agreed on this point. But at the same time, corporate-sponsored open source projects (like MySQL) are uniquely vulnerable when compared to multi-vendor ones. The hard news to break to the HN crowd is that multi-vendor projects (like PostgreSQL), despite the fact that they are fundamentally more difficult to monetize, will eventually out-compete the single vendor ones which are more friendly to the start-up model.
I googled app-centric after reading this and I've come up with comparisions made with mouse-centric, computer-centric, user-centric and I don't really understand it. Are you using it as a synonym for single-user?
Basically the issue has to do with how MySQL folks and PostgreSQL folks see the RDBMS.
MySQL users see the RDBMS as the bottom tier for the applications they are developing. Consequently the system's design is aimed at letting the application steer the interaction. If the application wants to treat 30 February as a valid date, that's the application's call and the app can set sql_mode appropriately and allow such values to be stored or not.
In other words, with MySQL, the db is there primarily to serve the application.
With PostgreSQL, it's very different. The database is there not to serve the application but to manage data. The applications are just users of that managed data. In this model the database has a very different responsibility. You might therefore call PostgreSQL data-centric. Applications cannot decide how strict data handling should be because that would defeat the whole purpose of the RDBMS in the PostgreSQL worldview, which is the system which manages and ensures meaningfulness of data.
So MySQL sees the RDBMS as ultimately serving (and being accountable to) the applications and app developers. PostgreSQL sees it as ultimately being accountable to the data and DBA's. The problem is that this makes MySQL have trouble when multiple codebases are used to access the same data since each application could conceivably be operating on different sql_mode settings. Each application can therefore be seen to be interfering with the other apps' state rather than all consuming shared managed data.
Hope this helps clarify things.
One of the things I really liked about Firebird the last time I played with it is that it could be run over a socket or embedded as a library. The PostgreSQL community will not provide a library engine because of the fear that application bugs may cause corrupted data structures in the library. Again this is wholely consistent with PostgreSQL not really caring about the single app space that much.
What this means is that if you want to distribute an application, you can actually directly link your application to the database management component directly and this simplifies the management of your app. If you need to later move the app up to a dedicated server you can do that. Firebird makes this really easy and it does so without creating the flexibility on input (and hence the fact that so many variations must be handled on output) that MySQL does.