I often saw how people included hibernating into a project, not really thinking about whether they really needed it. And after some time, when the service grew, they began to wonder if this was a mistake. Let’s try to think ahead of what the pros and cons of hibernate are in general so that next time we can determine whether we need to add this dependency in a new microservice. Perhaps it makes sense to get by with simple , without all that JPA complexity? Spring Data JDBC Bunch of non-obvious things Hibernate may look like tons of annotations that magically select everything from the database and save it. All we need is to add , , and other annotations correctly. @ManyToMany @OneToMany If you dig deeper, many programmers in job interviews cannot tell exactly how their application works. For example, in the code below, we do not explicitly call the method anywhere, but changes will be saved in the database. save() { Account acc = accRepo.findById(accId).orElseThrow(RuntimeException:: ); acc.setLastName( ); } @Transactional public void processSomething ( accId) long new "new name" To me, this kind of code makes it dramatically harder to read. Code reviewers will spend a lot of time figuring out what’s going on. And the next time you have to fix a bug, it will take a lot of time. Lazy fetching issues (fetch = FetchType.LAZY) (name = ) Company company; @ManyToOne @JoinColumn "company_id" private Another common occurrence is the use of Lazy fetch in transactions. It seems tempting to add a lazy field to the entity and refer to it in a transaction to get the data. Then one more field is added, and one more. We most likely don’t need all of the data except 1–2 fields of several objects. But as a result, the application sends 5–10 requests to the database, completely pulling out objects. Instead, it is possible to write one select requesting only the necessary data. If the access to the fields occurs outside the service (and the transaction), there are still such ridiculous constructions that say hello to code reviewers: (readOnly = ) { Account acc = accRepo.findById(id).orElseThrow(RuntimeException:: ); acc.getCompany().getName(); acc; } @Transactional true Account public getAccountWithCompany ( id) long new return It would seem fetching or could be used. But affects other code, and requires a separate request (if we are already writing it, do we need a hibernate?). Eager @EntityGraph Eager @EntityGraph N+1 selects problem Writing code that will do batch inserts with hibernate is not an easy task. Don’t forget to: 1. Add a property to application.yml spring.jpa.properties.hibername.jdbc.batch_size: 50 2. Create a sequence increasing by the batch size CREATE SEQUENCE account_id_seq START 1 INCREMENT BY 50; 3. Setup sequence generator to use several sequence values at once. Otherwise, the hibernate will refer to the sequence N times. { ( name = , strategy = , parameters = { (name = , value = ), (name = , value = ), (name = , value = ) }) (strategy = GenerationType.SEQUENCE, generator = ) Long id; ... @Entity public class Account @Id @GenericGenerator "account_id_generator" "org.hibernate.id.enhanced.SequenceStyleGenerator" @Parameter "sequence_name" "account_id_seq" @Parameter "increment_size" "50" @Parameter "optimizer" "pooled-lo" @GeneratedValue "account_id_generator" private It often happens that people forget about the sequence generator, and this completely negates the entire optimization of the batch insert. What’s really handy with Hibernate is the cascading batch insert if everything is well configured. Since the hibernate first requests IDs, this allows setting foreign keys for cascade saving of related entities. You can do it without Hibernate by following the same scenario. Don’t forget to use to batch select entities associated with or annotations. Otherwise, N+1 requests will be executed. @BatchSize @ManyToMany @OneToMany If you nevertheless decided to use Hibernate, I recommend using the library in your tests to be sure how many requests to the database are executed exactly. QuickPerf ( ) { ... } @Test @ExpectSelect 2 public void shouldSelectTwoTimes () 2nd level cache Finally, it is worth mentioning the second-level cache in Hibernate. If you use the standard Ehcache implementation, then when the application is scaled, different instances will store different data in the cache. As a result, the response of the service may depend on which instance the request arrived at. To avoid this, it’s probably best to start using Spring Cache right away. Then, when scaling, it will be enough to connect a distributed implementation (Redis, Hazelcast, Apache Ignite, etc.). Let me also remind you that in using the L2 cache of Hibernate, a connection to a database will still be acquired for each request. : : INFO --- [ main] i.StatisticalLoggingSessionEventListener : Session Metrics { nanoseconds spent acquiring JDBC connections; nanoseconds spent releasing JDBC connections; nanoseconds spent preparing JDBC statements; nanoseconds spent executing JDBC statements; nanoseconds spent executing JDBC batches; nanoseconds spent performing L2C puts; nanoseconds spent performing L2C hits; nanoseconds spent performing L2C misses; nanoseconds spent executing flushes (flushing a total of entities collections); nanoseconds spent executing partial-flushes (flushing a total of entities collections) } 2021 -07 -26 20 20 44.479 55184 4125 1 0 0 0 0 0 0 0 0 0 0 12333 1 0 0 0 0 0 and 0 0 0 0 and 0 Conclusion I’m not trying to say that you should never use Hibernate. It can be useful in certain scenarios. But I want to say that you should always think about it in the early stages of a project not to regret it in the future. Also published here .
