[cipherboy]

If you have reproducers for behavioral differences, happy to take issues and PRs!

(Entities was discussed here: https://github.com/openbao/openbao/issues/1110#issuecomment-...)

Right, check out our vision post as well: https://openbao.org/blog/vision-for-namespaces/

By restructuring storage--which, may, yes, lead to some operational differences--we can add per-namespace seal mechanisms in our next release (v2.4.0 -- design doc https://github.com/openbao/openbao/issues/1170), giving encryption key separation. Layer that with per-namespace storage engines (or light partitions -- separate tables) and true horizontal _write_ scalability becomes a possibility.

[p_l]

Yep, I have been just reading that for unrelated reasons before happening on the HN post :)

At $DAYJOB I am currently dealing with rather huge Vault Enterprise install with lots and lots of namespaces.

Honestly my biggest question is how compatible using things like kubernetes operators for Vault with OpenBao instead is - it's my main hosting platform across all projects, so very interested in integration stories there

[cipherboy]

Nice! The biggest gap with Vault Enterprise that I'm hoping we'll get to next release will be horizontal scalability of read requests.

We should be fairly compatible otherwise! Our helm chart just got a few more maintainers (I confess I lack the skills to maintain it, JanMa has been doing a great job there) though we've been relying on the pre-BUSL operator and CSI from upstream due to lack of resources.

Things like ESO and Cert-Manager should just continue to work :-)

[JanMa]

We've made an effort to keep API compatibility with Vault wherever possible, also with the new namespaces implementation. Most of the tooling which works with Vault today will also work with OpenBao