MySQL Database filesystem standard

The file system is useful if you are looking for a particular file, as operating systems maintain a sort of index. However, the contents of a txt file won't be indexed, which is one of the main advantages of a database. Another is understanding the relational model, so that data doesn't need to be repeated over and over. Another is understanding types. If you have a txt file, you'll need to parse numbers, dates, etc.

So - the file system might work for you in some cases, but certainly not all.

On second thoughts I'm thinking it'd be a bit redundant anyway as the database connection credentials will need to be stored on disk for the rails app anyway!

You've essentially summarised your problem.

Even if you could encrypt the MySQL store - "all" they have to do is compromise your web server, and they get your DB credentials and can happily dump your database. The fact really is that if they can get the same level of access as you at any point - all your security efforts have gone down the drain.

Here are some general tips, but they don't replace your professional security advice:

• Minimise access. Never have a user that can access the database server from any IP address, you're just begging for a brute-force attack. Instead, tweak the external firewall (e.g. the one EC2 called "Security groups") so only your web server can even connect to your DB server. The less people that know your VPS is a DB server, the better.
• Make sure everything else is secure. That means your email passwords, security answers, and so on. If they can get access to your EC2 account or your email account, you've just completely wasted your time securing the instance. Social engineering attack are all the rage these days, don't let yourself be next.
• Ensure your VPS instance is bare-metal. Don't have software on there that doesn't need to be, that even goes for sendmail (this is just an example of how, back then, you might have though "sendmail can't hurt to leave on!"). Anything that is there, keep updated frequently and watch out for security notices.
• Try to avoid having any services in general that are public facing, especially something like SSH. If you must, disable password authentication and put SSH on a non-standard port (then connect to it like ssh -p <port> user@host as normal.

Having said all of this, it won't make your case to the client any better. You'll still say "it's as secure as it can be" but not "the data is encrypted on disk".