Open source & cheap 'data at rest' encryption solutions So I am exploring some options about database encryption. The best options are commercial (TDE). I am looking for an open-source implementation. Recent releases of MySQL and MariaDB have data-at-rest capabilities:
MariaDB
https://mariadb.com/kb/en/mariadb/why-encrypt-mariadb-data/
MySQL 5.7.11 comes with InnoDB tablespace encryption
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html
What is important in this implementation (for companies) is: are these compliant with PCI-DSS / HIPAA etc?
From MariaDB:

The MariaDB file_key_management plugin enables the configuration of keys in a file. The key file is read at system start and no additional access is needed during runtime. The security of the encryption depends on access restriction to the key file. The key file can itself be encrypted, providing additional layer of protection.

From my point of view this will mean providing the decryption of the key during start (and OS reboot)? So whenever we (re-)boot a system does this mean we need to manually provide this key? Having this key readable on the server itself will defeat the use of data-at-rest encryption in the first place.
In MySQL 5.7.11+

The InnoDB tablespace encryption feature in non-enterprise editions of MySQL use the keyring_file plugin for encryption key management, which is not intended as a regulatory compliance solution. Security standards such as PCI, FIPS, and others require use of key management systems to secure, manage, and protect encryption keys in key vaults or hardware security modules (HSMs).
MySQL Enterprise Edition offers the keyring_okv plugin, which includes a KMIP client (KMIP v1.2) that works with Oracle Key Vault (OKV) to provide encryption key management. A secure and robust encryption key management solution such as OKV is critical for security and for compliance with various security standards. Among other benefits, using a key vault ensures that keys are stored securely, never lost, and only known to authorized key administrators. A key vault also maintains an encryption key history.

Now I am wondering, can this be made compliant with security standards? When using this data-at-rest, will root or mysql user have access to the keys since they could read encryption keys from memory?
Data-at-rest
There may be a terminology problem here. Data-at-rest encryption usually means

Storage-encryption
Not peer-to-peer nor any other form of data-at-use encryption.

On the forms of encryption suggested, I would advise staying away from those RDBMS-specific solutions as they're less tested than the other options which PostgreSQL suggests

Storage encryption can be performed at the file system level or the block level. Linux file system encryption options include eCryptfs and EncFS, while FreeBSD uses PEFS. Block level or full disk encryption options include dm-crypt + LUKS on Linux and GEOM modules geli and gbde on FreeBSD. Many other operating systems support this functionality, including Windows.
This mechanism prevents unencrypted data from being read from the drives if the drives or the entire computer is stolen. This does not protect against attacks while the file system is mounted, because when mounted, the operating system provides an unencrypted view of the data. However, to mount the file system, you need some way for the encryption key to be passed to the operating system, and sometimes the key is stored somewhere on the host that mounts the disk.

Essentially, different operating systems and file systems abstraction layers provide a better better-tested method of handling data-at-rest encryption.
Yes, that means you have a key. Yes, that means if the key is compromised the data can be read. But if your database is compromised and not the key, the data is secure. And, that's why it's data-at-rest.
So you normally store the key owned by root. Have root mount the secured location, and let the postgres user access that. Obviously PostgreSQL needs access to the data and has to know how to decrypt it.
Now, if other users are on the machine they can't access the data unless they're they postgres user. Moreover, they can't access the key. And if they do manage to compromise the data or even steal the physical encrypted back up they can't access it without the key.