I don’t have any formal benchmarks, but here are some practical observations…
If the database layer involves any network communication, then the time spent in Permazen is usually dwarfed by the time spent in the database layer. This is due to the fact that in general, moving around bits in memory is a lot faster than moving around bits across the network.
Permazen tends to generate a larger number of smaller volume database accesses than e.g. JPA. For example, with ORM solutions you typically read all of the non-collections properties of an object at once (in a single table row), whereas Permazen reads each field “on demand” individually. In addition, with ORM solutions SQL not only serves as a query language but also as a way to effectively batch up requests and responses, which saves time when the database has high access latency (e.g., over a network).
So for these reasons, from a performance perspective, Permazen works best with underlying databases that have low latency for access. Consider for example what persistence layer you’d want to use in a system with a fast local persistent memory (e.g., see this).
There is a key/value caching layer that somewhat helps with higher latency databases, but what would help more is an analogous ability to “batch” query the database. This is something being worked on.
Like with a lot of software, there is a spectrum of trade-offs from performance to conceptual elegance. Permazen is definitely an attempt to think about the latter side of that spectrum in the persistence domain.