Gov't GSA Office goes MySQL
comforteagle writes "MySQL has won a five year contract with the US General Services Administration office putting it in yet another government office on top of NASA, the Dept. of Def., Los Alamos National Labs & the Census Bureau. This additional win allows around 70 Government customers to purchase and deploy MySQL."
What exactly are they paying for?
"MySQL has won a five year contract with the US General Services Administration office..."
...did the US General Services Administration office win?
Honestly, who doesn't call it DoD? Even scientists do!
If your priest was a hitman and your sister's pimp needed to clean up a mess, then yeah, you might get a discount on Postgres for the referral.
What stopped them from deploying MySQL before?
Wake up tomorrow and sell Perl/PHP contract to government.
GSA is not just another gov't office. Once you are on the GSA Schedule, then many other government offices and agencies can simply buy your product without any additional paperwork. This means that the on-ramp to MySQL just got *much* easier for many groups in the U.S. govenment.
To quote: "With the GSA contract, GS-35F-0131R Schedule 70, government customers will be able to purchase and deploy MySQL through Carahsoft Technology Corp. The GSA schedule is effective Dec. 20, 2005 through Nov. 19, 2009."
See the magic words "GSA Schedule?" This is a Very Good Thing(tm).
This is certainly useful, in that it makes the product available to Federal users at a known (and, since it's on a GSA schedule, typically better-than-average) price. But when a reseller negotiates to be the GSA dealer for an item, that's all they've accomplished. That's NOT the same as actually talking an agency into using the product. We also want to be careful not to draw the wrong conclusions. When they say that NASA is using it, that means it's one more tool in NASA's toolbox. Some people might get the impression that they're using in lieu of other DB engines, rather than along side of such.
Don't disappoint your bird dog. Go to the range.
They recommend that all commercial entities use the commercial license. And if you call them to discuss the ins and outs of their licensing scheme, they'll try to talk you into the commercial license anyway.
Here's a nice blog entry about this scariness.
P.S. You're right. You *are* the bad analogy guy. You win.
Writerati
Choosing to go with a database that doesn't support foreign keys.
-- "I can't tell the future, I just work there." -- The Doctor
Support?
In my years of computing, I have only had to call on professional support services, two times.
Now a days I just subscribe to the mailing list and spend some time on Google.
Maybe they are using MySQL in other ways, but I can't imagine in such a way that they need any amount of support.
The fact of the matter is, in this post-SOX world business and governments needs to hedge their bets EVERYWHERE they can, and ensuring ongoing support services, upgrade protection, etc etc is how you can DOCUMENT steps taken to remediate the risks to integrity, availability and confidentiality. I like OSS, the people that support and write these application build into them wonderful security measures, precautions and a framework to utilize so many more security tools - but without a support agreement the application will never make it in the door. When that mission critical server crashes Google ain't gettin on a plane to come help you out.
http://dev.mysql.com/doc/refman/5.0/en/innodb-fore ign-key-constraints.html
Are you German? Like, er, whoooooosh or something.
I love you. No. Really. I love you, man.
"The federal government will spend in excess of $400 billion with contractors this year and over $100 billion is expected to be spent with small businesses. Now business people from all over the U.S. can learn first hand from the experts how to capitalize on these business opportunities with federal government agencies without leaving their own offices"
Sounds good to me.
So, someone wants to tightly link a GPL core to a proprietary tool and redistribute without releasing all of the source code. Who's supposed to be upset at this, other than the person releasing the proprietary product?
Want to argue that binary compatibility is OK - go have fun on the Linux kernel mailing list and argue that a device driver doesn't need to be GPL.
If someone is sure that a library tightly bound to a binary interface isn't a derivative work, they are perfectly free to act on that belief.
MySQL seems committed to the free software objective of making more software free. The company licensing and views support that objective.
Other projects have a different view and accept commercial use with no payback the community or developers. Their call. MySQL's is that if you're using MySQL, you should either also be releasing free software or you should be contributing to the development of the server the free community and everyone else is using.
It appears that MySQL believes that's the practice which produces a strong open source database company. With more than a million downloads in just the first three weeks after MySQL 5 was released a few months ago, as well as several hundred employees, it's getting pretty hard to argue with the success of that view.
Do we really need to continue to see this tedious "news" about every mundane adoption of every mundane piece of software (so long as it's open source)? Some people are using MySQL. We get it. Some more people are using Linux. We get that too. This isn't news. Not even for nerds.
I've seen your sister. Pretty desperate aren't you?
I know many consultants that rarely use tech support services. Not bragging, simply stating something I happened to notice about others in my field.
While I have limited experience in environments larger then a few hundred users, I can't imagine anyone is doing anything that goes beyond the scope of documentation.
Sure, I understand support for desktop users, that's a must, but for Administrators? It's my job to know what is going on at all times. If I can't fix it or get my hands on information that helps me solve the problem quickly, I'm not doing my job. I just don't believe that any support department can give me any information that I can't find on the Internet or via another consultant I know.
Maybe there should be a slashdot poll regarding support services usage...
How does a site handling 6,000 page views per second, around a billion queries per day on five database servers and in the top 40 sites in the world according to Alexa.com sound?
Or how does Google's main revenue source or Travelocity's booking system or big chunks of Yahoo or... do I really need to continue with more examples of massive web traffic using MySQL?
Site design can be screwed up. It can also be done right. People regularly do it both ways. The database server usually isn't the reason. The people using it are.
MySQL is on the GSA schedule - but thousands upon thousands of products are available on the GSA schedule. Just being on the GSA schedule isn't particularly dramatic, though. And the headline (and even the summary) are quite a bit more breathless and quite a bit less accurate than the real story.
-h-
That's bullshit, and you know it. Under certain circumstances if I integrate MySQL into my application itself (not just connect to a MySQL server), if I install and run MySQL as an integrated par of my application AND I distribute my application outside my organization than and only than do I have obligations under whatever version of the GPL MySQL uses. The GSA probably isn't going to have this application marketed to the public (or anyone outside the Government). You know these types of rules go for commercial applications, too?
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
i'm not sure you can draw valid parallels between running the infrastructure in a small business and running the infrastructure of a first-world nation.
Burried away in the licensing is a distinction between web servers on non windows playforms, and - everything else. PostgreSQL makes no such distinction, because it's always been and always will be free (as in freedom). Did you know you may need to pay for MySQL in a commerical $ENV? That's why projects like Asterisk shy away from it. They were quick to adopt Pg because it didn't pose that barrier.
After years of exhaustive, painstaking, and expensive study, our government has finally devised a method to buy something that's free.
I hope it at least comes with a $600 wrench or something...
This tagline is umop apisdn.
The government has a GSA? Even with such a homophobic President? And they're not using a Microsoft product? I think hell's about to freeze over.
________________________________________________
suwain_2
Obviously you have never worked for the government, nor have any clue at all about how they manage their networks, nor what kind of password/userID systems they use. C;early you are an idiot.
Jim Winstead will be speaking at SCALE 4x. He will cover the new features in MySQL 5.0 and 5.1. You can get a discount on a full access pass using the promo code "NEWSP" or a free expo floor pass using "FREE".
1. Sell a free product to the U.S. Government for huge sums of money.
2. ???
3. Profit!
What happened to their failover system? What happened to their pager? What happened to their backups? Was it the server down or did someone rename it and not change the PHP connection settings or... lots of other things.
If you use one server, you're going to get downtime sometimes. It's a fact of life. Design your systems for it because the power supply will fail, someone will turn the wrong box off or any one of a thousand other things will go wrong.
One box = certain failure. Just a matter of time. People often don't design in reliability and the people not doing that will not do it whatever the database server they are using is, because it's a people or budget failure, not a failure of the database server.
Look buddy, I don't give a damn who uses MySQL. MySQL basically wrote a big "fuck you" to all the users before the license change. Wasn't real nice of the MySQL AB to make such a decision. Even then! They place a complicated page on the licensing stating MySQL is GPL, however! they try to use some type of licensing BS saying if you use mysql on a deployed platform, you must pay fees. This is *not* how the GPL works. MySQL is *not* free software since the license change. I should be able to use a (for example) pure mysql ruby based client to access MySQL server without MySQL AB jumping down my throat. Its *perfectly* legal and *does* *not* break GPL if you use a per say.. proprietary library to connect to it when you are just trying to use the friggen library. Even then! Because I'm using a ruby library, the definition of "linking" or "using" a library doesn't exactlty fall in to a catagory of how ruby uses code(even other scripting languages for the matter, which use a pure *language here* solution).
Any comments? Because even when you start asking these type of license questions, you get flamed by everyone just because you've found a loop in their licensing scheme.
Troll Tech has basically the same "business model". I think it's a worrisome trend.
As for NASA, I know they're actually using Mandriva Linux (no, not just a few PCs). They probably are actually using MySQL as well. But like you say, maybe not exclusively.
First of all, it can be important to permit linking and distribution of open source software to proprietary software, for example as a means of driving a proprietary standard out of the market. The GNU project itself has released many libraries in a form that permits proprietary, closed source software to use them that way because they know it's important.
Second, if there is a single commercial entity in control of the development of a piece of open source software, that entity will pursue its own ends with the development of the software. For example, they'll choose which features to include and support instead of being end user driven.
I think Troll Tech and MySQL are both doing more harm than good for free software and open source software because they are using open source merely as tool to increase their proprietary business. That's the kind of abuse of the open source and free software models that we really have to watch out for and defend against.
What? You don't exclude MySQL failures from your search queries? Well duh you're going to find those that fail. I'm not the most avid fan of MySQL myself, but I think anyone can recongnize that the every site that could attempt to use any database, will fail in some portion of their efforts. It's not MySQL's fault. Just think if all the PHP n00bs tried using PostgreSQL, Oracle, or MSSQL out of the box. (I'm sure you'll find plenty of samples on the net for these to).
I would expect the payment has mostly to do with support. I've seen many situations where you *will* pay for support, regardless of the cost or licensing of the software. And you do it because you *know* it's the Smart Thing(tm).
Eager to serve the United States instead of letting some power-hungry turbonerds cause the BSOD that vaporizes the world (or corporate rivals), the Government once again has expunged the totolitarian empire from those who would attempt to undermind the national infrastructure or those nutjobs who think they are helping break down that enitity.
The good news is that we won't have to worry about anyone with an XBOX360 playing TNW with NORAD's BURGR supercomputer.
"The only winning move is not to play." --WOPR from Wargames
The Rapture is NOT an exit strategy.
Site design can be screwed up. It can also be done right. People regularly do it both ways. The database server usually isn't the reason. The people using it are.
....
You're entirely correct. But are [government drones] going to be anywhere near the standard that Google/Yahoo etc employ?
Obviously in _special_ areas they would be, but generally
Newer mysql supports sub queries.
As well, let's keep in mind that publicly releasing the source is dependent on the public availability of the app itself. Apps developed for in-house use are what we are talking about here with the original question. License fees and code access are not an issue with this type of use.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
So even the US government does not really care anymore for its own standards. I guess Oracle will feel relieved with their 'ISO SQL 92 minus datatypes and a few other essentials' product. It kind of makes the efforts of PostgreSQL and others toward ISO SQL:2003 (hint: each ISO SQL standard cancels the former one) futile.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I don't see why not. I'm not the OP, but who said anything about small businesses? If anything, larger businesses and governments should have more staff in-house. They should really rely on outside support more along the lines of a development liason, or something-- a technical resource the in-house "experts" can call to see why some portions of an application's code aren't as highly optimized, or to help identify bugs in the software that could cause catastrophic failure. If one man can keep a 100 seat installation running without having to call a company for support, couldn't that be scaled up such that 100 people could keep a 10,000 seat installation running in the same fashion? (Surely, it wouldn't scale that evenly, but I think the point is clear.)
When I think of "support" for a large IT infrastructure, I'm thinking partnerships for customized solutions and fast critical incident response, not "who do I call when my DB developer gets an error inserting a record into a table?".
I don't moderate anymore. Karma penalty for 90% fair mods? Can I mod that unfair?
Ever since the MySQL installer required a root password and disabled root connections outside localhost by default, while telling you that in clear language during the install process, it has been more credible as a simple installable RDBMS than some of the competition. FileMaker is another example of a database (of a sort, though) which makes sensible install defaults and then allows progressive expansion of capability without overwhelming the user with poorly documented options, but it is not as install-friendly.
I know it is fashionable for "real" computer scientists and DBAs to sneer at MySQL. But that's actually a sign of insecurity. Real mechanics don't sneer at zinc plated steel bolts because 316 is available: they just don't use zinc plate under salt spray conditions.
Pining for the fjords
BadAnalogyGuy, you truly are BadAnalogyGuy.
hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?
Both Steve Ballmer and Larry Elison were seen throwing chairs and screaming, "We are a going to fucking bury the DoD, we did it before and we will do it again".
The DoD was heard mumbling something along the lines of "you and what army" and went back to keeping democracy save for billionares everywhere.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Aye, subselects have been supported since 4.1.
Personally I believe MySQL won the popularity vote against postgreSQL due to better performance because it didn't have as many features, as MySQL adds these features the performance will get worse than postgres who have had the features since the beginning and have been working mainly on reliability/performance.
I know which I'd choose.
Time is an illusion. Lunchtime doubly so. - Douglas Adams
Geez. Tough crowd. I thought it was the funniest comment I've seen on /. all week.
;)
I guess you must be a MySQL user, and/or an American, right?
MySQL is junk and always will be.
It's like raid0, if you don't care about your data, use this.
Not to mention SLASHDOT, LiveJournal and Wikipedia.
Not to mention SLASHDOT, LiveJournal and Wikipedia.
I think you are confusing high volume with high reliability. No-one really cares if a post gets lost or you get a timeout or breakdown on those sites. (I regularly get error pages on Wikipedia, for example).
generally speaking NO. there are a lot of great economies in scale but running a small 100 seat organisation is nothing like running a 10,000+ seat.
when a 100 person company has a server issue it is a hassle as 100 people can't work, when 10,000 seat company has a server or app problem 10,000 people can't work, even minute counts in this situations. If you tell your boss sorry I have no support agreement for this app but I will google it and I am sure I will find an answer eventually then your ass will be justifiably out the door before you can finish the sentence. peoples time costs money, larger companies mean app failures are more expensive. 1 hour of outage for 10,000 users is 10,000 hours of downtime. So it is not that large orgs can't solve the problems it is the problem MUST be solved in the shortest possible timeframe and a support agreement helps facilitate that.
Is this the first time this has happened, though? A quick look at the GSA Advantage site yields at least one or two results for MySQL database license vendors. Besides which, I don't see any MySQL products on the GSA Schedule mentioned in the article, either. To be fair, it can take some time to update GSA's information, but it may be better for these folks to make public announcements after the t's have been crossed. Still, this is a positive step in the right direction for greater use and support of MySQL in the US federal government.
Actually, I'd say the opposite is true (to a point). If you imagine that a manufacturer support agreement will get you out of a hole faster than your own talented staff who know the source of the software you use, you're naive. My own experience with vendor support is that very often they waste a lot of your time while they persuade you that it's your fault (your hardware, wrong firmware, wrong drivers, security patches you've installed) rather than providing instant access to high-level technical resources. If you are using an open-source product, then you may be better off maintaining in-house expertise (and a support backstop) but the support contract won't help you in an emergency as much as your own staff will.
This morning, the NYTimes reports the GSA's website for contract bidding has been shut down due serious security flaws.
c ure.html
http://www.nytimes.com/2006/01/13/technology/13se
"The security flaw, which could have permitted contractor fraud, was reported to the agency's inspector general on Dec. 22, but almost three weeks passed before the system was taken offline Wednesday afternoon. The General Services Administration is the federal agency responsible for procuring equipment and services, including computer security technology, making the lapse all the more striking. "This is the government entity responsible for letting contracts for security," said Mark Rasch, chief security counsel for Solutionary, a security firm. "Clearly the people who log in would know about security.""
Being on the GSA doesn't mean you sold anything, it just means you're on a list of vendors that it's easy for government agencies to buy from.
I've seen a LOT of database installations in government, and in MySQL's market it's almost all MSSQL and Oracle. They may get a few buys, but so far those in the goverment I have seen running MySQL weren't the type to pay for support.
If your server crashed, would you rather spend a couple hours digging around for a solution or call someone up who can answer your question? Also if I recall correctly, MySQL support will do more then just help fix a crashed server, they will help optimize your settings and schema.
There are basically to types of people when it comes to support:
Those who will spend money to save time (Buy a support contract) and those who will spend time to save money (mess with it on their own).
Next time you want to post a little dig like that, do it anonymously - I don't want everybody thinking Debian maintainers are all ignorant idiots who flame things they've clearly never used.
MySQL has had foreign keys for quite some time now, as long as your tables are InnoDB.
I certainly hope they don't use MyISAM tables. I'd like to think that the government likes stability more than speed.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
GSA does not have to get involved in truly free applications.
MySQL now is on the GSA schedule which just means it is easier for government agencies to use them and they have a vetted and approved price sheet (Fair and reasonable is what uncle Sam calls it). Now they have to get out there and win some contracts before they will see any money.
Moderation +4
50% Funny
20% Troll
10% Flamebait
Apparently the percentages round down. Assuming every category has 6,6% rounding error, the difference between positive and negative mods is around 13%, indicating that a whopping 4*100/13=31 mods have been fighting over this joke. Guessing that the average story gets 100 mods, about 15% of the Slashdot crowd are aware that MySQL now handles foreign keys and get upset if someone believes otherwise.
I further postulate that less than 30% of Slashdot readers are that knowledgeable about MySQL, giving a minimum of 50% of MySQL afficionados who are humorless and quick to anger.
As a big fan of mysql this is something that I like to see happen, I personally love mysql, I think it does a great job. I know we use it at work in a 32 node cluster for our backend processes.
AFAIK it doesn't matter just use base 64 to convert it to ASCII then it can store it easily, like in php I think it is base64_encode().
Michael-m.co.uk - Home of Michael Mulqueen
The more MySQL sites, the brighter my future.
not all support places suck, yes I find oracle and IBM are atrocious and tend to blame you before admitting fault, suprisingly MS though is one of the better ones and we have had many instances where they have saved us countless hours of downtime through there debugging of the issues. skilled staff are great, but no matter how skilled they don't beat the actual developers that wrote the software.
At Wikipedia we're still concentrating on using the donations to try to keep up with the growth and that's enough strain on resources already. Not likely to get much more reliable until growth slows down and donations have a chance to catch up and start paying for reliability more than sheer capacity. Can't stop trying to grow the capacity because that would cause timeout failures in page loadings and worse apparent reliability.
The best remedy for now is donations when money is asked for. It probably won't dramatically improve reliability this year but it might let us keep up. Might help reliability more next year. Depends on how donations to pay for the capacity for this years growth go and on how long the growth continues and at what rate.
It's an interesting challenge to do what Wikipedia is doing on donations.
At Wikipedia we're still concentrating on using the donations to try to keep up with the growth and that's enough strain on resources already. Not likely to get much more reliable until growth slows down and donations have a chance to catch up and start paying for reliability more than sheer capacity. Can't stop trying to grow the capacity because that would cause timeout failures in page loadings and worse apparent reliability.
My point was simply about MySQL - that there are circumstances where absolute reliability and transactional integrity is not required, and MySQL suits these situations. Personally, I would not trust it for a high-volume commercial site where transactions had to be totally guaranteed.
I was not complaining about Wikipedia as such - I think you do a great job!
Then the solution is redundancy. If a server goes down in a 10,000 seat organization, you damn well better have a backup server to switch to, and your network infrastructure damn well ought to handle this transparently while the technical people fix the real problem. If I go to the boss and say, "sorry, I have no support agreement for this app, but we've switched to the backup system and everything is working fine.. I'm going to go google it and we'll get it back up ASAP", I expect a positive response because I saved money on the support contract and provided a 0 downtime.
1. When do the actual developers do tech support instead of developing new software?
2. MS caused the problems, and everybody knows their software is full of bugs and misfeatues, so I find it easy to believe that they help you out a lot with debugging.
For load and transactions, I'm pretty comfortable with it. Could probably find a suitable architecture for most real-world cases. Not all.
That's not all there is to reliability, though - the other part is harder: protecting the data from application developers screwing up or deliberately attacking the system. MySQL is definitely not yet suitable for cases where inside developers will be attacking, unless there's a trusted middleware layer or other protection present. The old data validation criticism of MySQL is just one tiny part of this particular problem.
For load and transactions, I'm pretty comfortable with it.
I just don't see the point. For transactional safety (and I work in a place where the mains power occasionally blows, so I really need this), we have to use InnoDB tables with MySQL. But then you lose some of the high speed advantages of MySQL. So why not just go for a products that has always had transactional safety, good performance, and better SQL support without the bother of having to select table types, like PostgreSQL? - I simply can't see the advantage.
InnoDB isn't necessarily slower. It depends on the application. For LiveJournal they found it faster when they switched from MyISAM to InnoDB, for their mostly write load. It has the advantage of controlling both index and data record caching and it seems to do that significantly better than the operating system, so if it can stay ahead on transaction fsyncs it can come out ahead.
Benchmarks say that MyISAM is faster for parts benchmark load if transactions aren't needed, particularly for truly random read only access, but I'm not so sure in the real world, where you're able to design based on knowing the properties of the engines and can exploit them instead of having fixed schemas.
You probably know this anyway, but just for anyone who doesn't, bceause I really don't like telling people that they have no way to recover their data:
If your power goes out (as it will for everyone, if only due to emergency power off switch activation in a data center) then I hope you have a replication slave in a location on a completely different power supply, like a different state or country, because power outages have spanned many states and most of countries. One day, the filesystem or database or whole computer isn't going to survive the outage (or fire or flood or whatever) without corruption and copying from a slave beats backup restore and binary log replay.
Benchmarks say that MyISAM is faster for parts benchmark load if transactions aren't needed, particularly for truly random read only access, but I'm not so sure in the real world, where you're able to design based on knowing the properties of the engines and can exploit them instead of having fixed schemas.
But this is what I don't understand - why bother with a database where you have to design knowing the properties of the different engines (e.g. InnoDB)? Why not just use one like PostgreSQL where you know you are going to get performance and reliability without this sort of tuning?
If your power goes out (as it will for
everyone, if only due to emergency power off switch activation in a data center) then I hope you have a replication slave in a location on a completely different power supply, like a different state or country, because power outages have spanned many states and most of countries.
This issue isn't what I was talking about. I was talking about a database having atomic operations so that if there are power outages then the database is in a consistent state on recovery. Some table types in MySQL don't have this. PostgreSQL does.
When load starts to matter you always do have to design with knowledge of the properties of the storage engine in use. It's one of the reasons for the huge range of tweaking options some database servers have.
Consider one Wikipedia example. We keep the full version history for every article. We used to store those in order added, regardless of the article, so each version of each article would be in different pages in different locations on disk. That's the way the MyISAM engine always does it and if I understand correctly, the way PostgreSQL does it (but I don't know PostgreSQL that well, so I could be wrong).
Trouble is, that was extremely inefficient. With each version of one article in a different page we ended up doing fifty page reads to display a list of fifty versions. Worse, the code at that time wasn't very clever about how it went back further and you could ask for the versions between 50,000 and 50,050 and cause 50,050 pages and hence 50,050 disk seeks to be needed. That was slow and a denial of service attack vulnerability.
So, we exploited the way InnoDB stores records physically in primary key order and made the article ID the first part of the primary key. Now one page contains many revisions of the same article and displaying any number of revisions is painless.
None of this matters at low load. Once things get tough, though, I end up thinking about cache hit rates and disk seeks. That Wikipedia case changed lots of disk seeks with terrible cache hit rate to few seeks and excellent hit rate.
Ignoring RAM-only engines for the moment, PostgreSQL and other databases can't avoid such concerns because they also need to put data on a disk, read it and manage a cache efficiently.
Here's where the different MySQL engines also become interesting, because if you can't get a suitable architecture with one, there's a fair chance that another engine exists or can be developed to do what you need to get really efficient.
I see your point about atomicity but why do the engines in MySQL which don't offer ACID guarantees matter? Just don't pick one of those if you need that capability.
I see your point about atomicity but why do the engines in MySQL which don't offer ACID guarantees matter? Just don't pick one of those if you need that capability.
To me it matters because of the general culture around MySQL - it had a sort of 'quick and dirty' approach for years where things like modern SQL support and atomicity where initially not considered important, and then retro-fitted later. No matter how good this retro-fitting is, I personally feel more comfortable with a product like PostgreSQL, where the quality and integrity of data was a primary consideration from the start.
However, this has little relevance to your organisation, as your needs are complex, and I can see how the different capabilities of MySQL can be useful - as with your point about the different engines.