Came here to ask just about that but I see it's on your roadmap already, that's good and godspeed with that since encryption is hard.
During my PhD, I worked a little while with threshold encryption schemes (sometimes called horcrux encryption schemes, i.e. make n keys, you need at least m of them to perform some operations) (ref. my noob-ish question here ha https://crypto.stackexchange.com/questions/74763/is-there-an...).
I created a small system that allowed one to reconstruct parametric data from 3D shapes, but if and only if you had at least n pieces of the whole model, because reasons.
Reading this announcement, I recalled several things that came up during my research, which apply to this context as well.
* How can one make sure that losing one key is not the end of the db (i.e. backup keys)?
* How to share db access but not individual keys? (i.e. one key per user BUT all of them can read)
* What if encryption is shared by n users but one of them loses their key?
* How many keys for encrypting (or just one?), how many of them for decrypting?
* Represent all of this in some sort of stateful model, after all it's a db (in my case it was files), it's meant to be cold storage, everything should to be able to be reconstructed/recovered from there.
The list goes on and on ...
Anyway, just wanted to say that this is a very interesting and promising feature to be found in a database. Great work, I'm eagerly waiting to get my hands on this.