1.5k stars · Apache-2.0 (Community Edition) · 0.96.0 (2024-09-09) · Track this in Scout
A proxy that encrypts individual database fields on the way in and decrypts them on the way out.
▶Repo detailsthe review · specs · pros & cons · install
What it does
AcraServer stands between your application and PostgreSQL or MySQL and speaks their wire protocols, so to the application it looks like the database and to the database it looks like a client. You tell it which tables and columns are sensitive, and it encrypts those values as they are written and decrypts them as they are read, for clients that hold the right keys. It can also do the encryption inside the application instead, through client libraries, so values are already encrypted before they leave the process. On top of that it offers searchable encryption, where an exact-match lookup still works on an encrypted column, masking and tokenisation, and it logs queries so unusual access patterns can be spotted. Keys are managed separately from the data, with rotation. It does not encrypt a whole database file, which is what a disk-level feature does, and it does not support every database — PostgreSQL and MySQL are the supported ones. It is also not a secrets manager for application credentials.
Why it matters
Who it suits. Anyone storing personal data in PostgreSQL or MySQL who needs a specific answer to "what happens if the database is copied", and who cannot change the application much. It fits a small team facing a compliance question with no budget for a commercial product. Skip it if whole-disk encryption already satisfies your requirement, because this adds a service in the data path for protection you may not need, and skip it if your database is not one of the two supported.
Verdict. A small project doing a serious thing, and the reason it earns a place is that field-level encryption with searchable columns is rare in open source — most of the alternatives are either narrower or commercial. Be clear-eyed about three things. It is open-core: the Community Edition is Apache-2.0, and the company sells an Enterprise Edition with features held back, so read what is in which before building on it. The last tagged release is 0.96.0 from 9 September 2024, while code was pushed on 23 April 2026, so development continues without shipping, which is a gap worth knowing about. And a proxy in the data path is a new thing that can fail, so test what happens when it does. If the problem is secrets rather than stored records, Edition 50 covered Infisical/infisical and Edition 24 covered getsops/sops, both of which solve that instead.
- Speaks the PostgreSQL and MySQL wire protocols, so the application often needs no rewrite.
- Searchable encryption keeps exact-match lookups working on encrypted columns.
- Keys live apart from the data and can be rotated.
- Open-core. The Community Edition is Apache-2.0 and some features sit in a paid edition.
- Last tagged release September 2024, with code pushed April 2026. Active, but not shipping.
- A proxy in the path between application and database is one more thing that can break, and it costs some latency.
- michelp/pgsodium
Encryption inside PostgreSQL itself as an extension, so there is no proxy; smaller in scope and no searchable encryption or query logging.
Track this in Scout - openbao/openbao
Stores and hands out secrets, certificates and keys, and can encrypt values on request; a different job, and the right one if what you need is key custody rather than a database proxy.
Track this in Scout 
getsops/sopsEncrypts values inside configuration files rather than inside a database, for secrets kept in version control. Covered in Edition 24.
Track this in Scout
git clone https://github.com/cossacklabs/acra cd acra ls examples
