As a longtime Oracle user, I always felt that MySql was in “catch up” mode. It only developed ACID-compliant transactions and Declarative Referential Integrity begrudgingly, after InnoDB came along, and even then was still missing “big” database features like point in time recovery.
Still at some point early in the new millennium, MySql matured enough for me to ditch Oracle and start migrating our corporate databases.
I confess the primary impetus was cost, but a close second was the relative simplicity of MySql. The installation was tiny and it was easy to get started and it just was a perfect fit with our switch to Linux and Open Source in general.
Over time we worked out the kinks and I never regretted the decision. There were always a few Oracle features I pined for, but we eventually came to be truly enamored with MySql. And although it never did get point in time recovery, we eventually became confident that we could (sort of) simulate that in the event of a disaster with a nightly backup and the transaction logs.
This was with accomplished with statement based replication, a unique and scary feature that we found actually worked for us.
A big plus was the relative simplicity with which we got multi region circular replication working, something I never was able to deploy with Oracle.
The last couple years though, my relationship with MySql began to sour. It’s not just for the politically expedient reason that Oracle came along and bought it (grand conspiracists of course assume that was to slowly kill it without leaving a smoking gun), but it truly has stagnated the last few years.
As times have changed the one crushing thing that Mysql still lacks is of course table or tablespace level encryption. Everything else is negotiable, but in 2016 there is just no excuse for storing data in plaintext. This issue barely existed a decade earlier but it has become harder and harder to justify using a free database when Oracle has had this feature for decades.
We ran up trial balloons of various workarounds, including full disk encryption, but were just not able to get where we wanted to go with anything short of encryption built directly into the DB layer.
And so just around the time we (painfully) started to consider a migration back to Oracle, the heavens opened up. The original developers of MySql revolted and forked a version called MariaDB. While initially it wasn’t much of a different product – one of the recent promises was to build table level encryption into it using code contributed by none other than Google.
This immediately piqued my interest, and I started beta testing MariaDB and we eventually migrated to it last year while still waiting for the promised encryption.
Finally late last year, whole table encryption arrived, and, it worked!
We took the plunge in the first quarter of 2016 and finally can rest just a tiny bit now that 100% of our corporate data is safely encrypted behind a strong key.
Of course, having your data encrypted is only a small part of our overall security footprint (albeit a pretty important one). We certainly aren’t resting on our laurels now but are off trying to revisit every other aspect of security.
MariaDB whole table encryption met our needs. They also threw in encryption on logs and such, and launched a really impressive product with just a few limitations I expect will be addressed before long.
It’s been completely stable in the couple months we’ve been live and has exceeded our performance expectations.
You can find more information at Data at Rest Encryption on the MariaDB site.