We’re currently upgrading our project with Spring Boot 3.5 with Hibernate 6.4 to Spring Boot 4.0 with Hibernate 7.2.
The performance is 5-10 times slower than before. The queries against the database itself are faster as before, but the time between the queries is increased. It looks like that hibernate spends much more time in object hydration as before. A query with 8.000 results tooks 700ms with Hibernate 6 and 9s with Hibernate 7.
Thanks for the report, but we will need more details than that.
Please try to create a reproducer with our test case template and if you are able to reproduce the issue, create a bug ticket in our issue tracker and attach that reproducer.
Hi @beikov , we’ve experienced the exact same performance degradation after upgrading to Spring Boot 4 & Hibernate 7! We still couldn’t find the root cause of it, but just wanted to let you know that +1 here 
Hello,
This response seems to be automated, And doesn’t help in solving the issue - It’s not a bug BUT a fact that hibernate is failing to scale…
No one is going to provide a reproducer that involves 300 - 500 entities, And these are private production models…
Anyway, We also have the same issue and on debugging, Metamodel processing takes a lot of time, And we also realised that some requests to services through the service registry somehow hung…
Suggestion, After looking at the source we noticed one thing, The session factory boot-up seems to be single-thread, And maybe employing multi-threading would somehow help - They’re many loops in there that can actually be optimized…
We all know during development and testing, Developers mostly use a few entities BUT trust this, If you run hibernate on 300 - 500 entities, It will take 1+ minutes just to initialize the session factory…
And Spring also adds time for component scanning and bean registration, And the total can easily shoot up to 3+ minutes, Now just imagine opening up a desktop application and waiting for such a long time…
Please note, These were not issues in hibernate 5, Somewhere somehow whatever changed, Is not optimized enough for production…
Thanks.
If you care about bootstrap performance, you have various solutions like compiling to native with e.g. Quarkus. In addition, frameworks like Quarkus do a lot of the discovery at build time already, so startup of the application is quite fast, even without native compilation.
We understand that the bootstrap can sometimes be slow when lots of entities are involved, but there are many knobs you can turn to improve startup and we’re constantly working on improvements as well. Parallelization is a bit too complicated, because the bootstrap process changes mutable state all the time, and it’s very hard to synchronize everything properly.
We treat performance regressions as bugs, so if you have performance trouble that you didn’t have with earlier versions, we will look into that. Having said that, without any flamegraphs that show where time is spent or a reproducer, we can’t do anything. It would just be poking into random areas that are probably not the root cause of the problem. So no, the answer is not automated, but without any details, we can’t reasonably do anything.