This is an excellent opportunity to demonstrate that anyone can fork the MySQL codebase and create other plug-in replacement databases with it, such as MariaDB and Drizzle.
All that is lost is the MySQL name and brand.
PostgreSQL users and developers must seize the opportunity to show businesses that free software cannot be killed, not even by mighty Oracle. They and, most notably, Microsoft, have been trying to kill it for more than a decade now.
Because the anti-free-software FUD machine (fed in part by Oracle itself) is already having a wonderful time with this.
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.
Most of us have suspected that the MySQL project itself was going to die as it was acquired by Oracle, in the same way Open Office died when it was acquired by Oracle. This is a company where good software goes to expire, either due to a deliberate intention or gross incompetence I can't say but I suspect it's a mixture of both. However sad that may be for the MySQL (or OpenOffice) brand name, the code itself lives on and continues to evolve within a rich open source ecosystem.
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.
The corporate assassination of open source projects will only work if we let it, it's a purely psychological game.
I do agree that injecting postgresql into every discussion without adding anything new is getting excessive. And declaring mysql dead is clearly premature. But let me respond to this particular point:
"Show some solidarity with a fellow open source project!"
I guess I never really saw MySQL as an open project.
* when I first started using mysql it was not under the GPL, it was under some free-for-non-commercial use license
* They pretty much reject the standards completely (introducing nonstandard things like backticks that make migration away from mysql harder for no apparent benefit)
* mysql never fostered an outside developer community (by which I mean people developing mysql itself)
* the code is messy and poorly structured
* the development ecosystem, like revision control and documentation (and now tests) don't seem to be open
* the licensing of the client library is restrictive
* they require copyright assignment (although not all of the forks do)
I hope one of the forks does manage to foster a more open community, but communities aren't built overnight nor are they transplanted easily.
Of course when you're talking about community, every project seems to have a different atmosphere. Linus Torvalds is famous for not accepting patches or contributions to the Linux kernel, so is that project really open? From the perspective of a developer using MySQL, the community has always been massive, diverse, and helpful. Maybe it was a different experience on the dev mailing list, I wouldn't know. But I do know that in the end, MySQL was open where it really mattered.
I can understand though that it was probably easier and more rewarding for an outside developer to get into the inner circles of Postgres than it was to essentially join MySQL AB back in the time when they still existed.
> I hope one of the forks does manage to foster a more open community, but communities aren't built overnight nor are they transplanted easily.
I assume you're talking about the actual engine development community, and I'm not certain that's really how a lot of open source projects actually work. It seems in most cases you simply have a core group of developers doing their thing, with occasional discussions and input from the outside. I might be wrong, but that's certainly my perception. The Postgres dev community might be different, again I wouldn't know.
As an app developer, I have different expectations about that. I'm not going to take part in any discussions about implementation details, nor am I likely to submit any patches. What I care about is software quality and proper documentation, those are not necessarily a function of community.
Agreed. My perception is more that it is turning out to be one and that is a good thing.
"But I do know that in the end, MySQL was open where it really mattered."
The GPL means that there's no real fear that licenses will be scarce. And the large user community means that there will always be people to offer basic support (free or paid) and consulting. To that extent, I agree.
As far as getting bugs fixed, adapting to new use cases and changes in the market, or just moving the product further, the jury is still out. Will Oracle do it? Can any of the forks do it?
Or the larger question: are you OK with calling MySQL, as a product (i.e. the engine), "done"? I'm not saying that in a negative way. We rarely talk about software that's done, or what it would take to finish a given product, or how much sense being "done" even makes.
"It seems in most cases you simply have a core group of developers doing their thing, with occasional discussions and input from the outside."
That's not how I would describe postgresql. There are lots of people that only occasionally submit patches and lots of people that take part in design discussions even if they never submit much code. It's pretty easy to start out as an application developer and then be sucked into a design discussion, and before you know it you are criticizing a design because it doesn't fit your needs.
Even if nobody has ever seen you before, if you jump into a design discussion and have a legitimate concern or use case that hasn't been considered then it will be taken as seriously as any developer.
"What I care about is software quality and proper documentation, those are not necessarily a function of community."
Absolutely correct. Although those things are also not a function of being open source or free of charge.
Perhaps Oracle's influence was a net positive. It continually reinforces that open-source software is more about contributing positively to the code rather than simply controlling the trademark. Mozilla could be seen as the anti-Oracle in this regard. The community believes their control of the Firefox trademark has been mostly a good thing.
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
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.
I respectfully disagree.
Building a community of database developers is no small task. PostgreSQL has spent a long time fostering a diverse group of developers, maintaining a clean codebase and infrastructure, and having explicit policies and procedures in place that make it easier for new developers to get started.
That has never been true for MySQL. Development happens largely because of the money that MySQL AB, then Sun, and now Oracle is paying.
Monty is trying to change that with MariaDB (I don't know as much about the others) and I respect that and I hope he succeeds. But it takes a while to go from corporate development to community development successfully -- it doesn't happen overnight, especially in a field like databases where it can be hard to find developers regardless of money.
Having one single corporate sponsor is always a very bad idea for open-source projects. I hope MySQL derivatives have learned this lesson.
And, I imagine, the dual-licensing thing has to go. That's no longer a viable way to sustain development.
Aside: why, oh why, did 3 mysql forks appear when MySQL AB was bought? Couldn't they coalesce around one alternative?
Ordinarily, I'm not against a little healthy competition. I think forks and trying new ideas is great. But the timing just makes no sense to me from any rational point of view.
"I suspect keeping up with it does not require as much effort as it did getting to where it is now... maybe... it will continue evolving."
True, but I'd hate to see the bar set that low.
Percona Server exists because Percona has a great deal of deep hands on knowledge about MySQL tuning and internals, and has a live-or-die commitment to making MySQL work well, and taking patches from it's user community.
Maria and Percona server advance more or less together, and routinely swap patches back and forth.
DrizzleDB exists because some of the MySQL developers decided that Doing It Right was more important than maintaining old targets and maintaining backwards compatibility.
There is plenty of room in the MySQL user and developer ecology for both approaches. If you need MySQL, and you don't trust Oracle, or don't want to pay them, just swap in MariaDB or Percona Server, they are drop-in replacements. In fact, you should drop them in away, they have more bugs fixed and are more performant than stock Oracle MySQL.
They had different goals. MariaDB was to maybe make another billion and Drizzle was to be more parallel and remove all the Windows specific code, IIRC.
It's not even that much to do - support INSERT IGNORE, ON DUPLICATE KEY UPDATE, INSERT REPLACE, and make a "relaxed" mode where too long strings are truncated and NULLs inserted into NOT NULL turn into 0 or the empty string and you are virtually all the way there.
I think it can be good to offer a few conveniences to make it easier to switch, but I think they should be limited in scope.
Postgresql is not trying to be mysql -- that need is already filled by MariaDB and others. Trying to pretend that postgres is mysql would just make users frustrated and disappointed.
Think about it like moving to a foreign country. The residents try to be as friendly and accommodating as they can when it comes to food, shelter, transportation, directions, etc. There are often even multi-lingual people in the critical places. But eventually the goal is to adapt to the local culture and bring a hint of your previous culture into the mix; not completely recreate your culture in a new place.
I suspect more than a few syntax adjustments would be required before users could rely on the port. The upstream project (e.g. wordpress) would need to be aware that their users were trying to use postgres in order for such users to be actually happy.
I could be wrong, but I have not seen a port of a real app that came down to just syntax differences.
It might be a different story between two implementations that follow the SQL standard reasonably well (MySQL is pretty far from the standard in many ways), but even in that case I'd be cautious.
Postgres is doing great being postgres. To the extent postgres can accommodate converts from mysql, or oracle or sql server, then also great. But we're too busy inventing new stuff to endlessly chase the quirks of other systems.
No there shouldn't be a mode in PostgreSQL for this. The problem is that this means abandoning the idea of hard data constraints.
It would be a cool kickstarter to fund something like this.
As we've seen for years PostgreSQL users will quite happily and naturally remind everyone how much superior it is to MySQL (and every other database) at every opportunity.
* you don't need transactions
* you don't need foreign key constraints
* you don't need ACID-compliance
Granted many of these don't apply anymore, but then legacies live on interaction-wise. This being said, I know very few real Pg users who harp on MySQL anymore. Most of us figure that Oracle does better advocacy on this area than we can.
More like, technically true, but contrary to the whole reason for doing what they're doing.
Nobody puts a lot of work into something "honestly" not intending to replace the thing it's replacing.
They say this to appease the people who point out that it doesn't do all the same things.
If I built a better alternative to a common item, you could bet your bottom dollar i would be very "honest" about it not replacing that common item. The last thing that statement would be is "honest." It's appeasement.
I also think the best way to look at NoSQL is that it is just a further development on Stonebreaker's bottom-left quadrant database division--- object databases.
The more I get into it, the more I am astounded with the power of PostgreSQL to take over all these workloads on the low-end and more.
Exactly. When NoSQL "honestly" say, oh nooooooooo we're not replacing the traditional RDBMS approach, this is anything but honest.
It's like me building this suspended-rail system for inner-city transportation. Oh noooooooo I'm not replacing traditional cars and bicycles!
the way you get acceptance is by faking honesty that you're not at all replacing the traditional approach (that you're replacing.)
The power of PostgreSQL occurs from the power to ignore the relational model and take other approaches when it is helpful.