Stage 1 - JPA Introduction: Database, ORM, JPA, and Hibernate
A database is a system that stores application data in a structured and durable way. A backend application can keep objects in memory only while the process is running, but real products need data after restart, across many users, and with rules that protect consistency. Relational databases such as PostgreSQL store data in tables. A table contains rows, a row represents one record, and columns describe the fields of that record.
Java applications can talk to a relational database through JDBC. JDBC is the low-level Java API for opening connections, sending SQL, binding parameters, and reading result sets. It is powerful, but it is also repetitive. If every service method writes SQL manually, the developer must build insert, select, update, and delete statements, convert each row into a Java object, handle connection boundaries, and keep SQL column names synchronized with Java field names.
Why manual JDBC becomes inconvenient
Manual SQL is not bad by itself. SQL is still the language of the database, and a backend developer must understand it. The problem appears when the same mapping code is repeated everywhere. A users table may have columns id, email, name, and created_at, while Java has a User class with fields id, email, name, and createdAt. With raw JDBC, each query must manually copy values in both directions.
That creates several risks. A renamed column breaks code in many places. A new field must be added to every insert and mapper. A common read operation requires boilerplate before the real business logic even begins. As an application grows, low-level data access code starts hiding the actual scenario.
What ORM means
ORM means Object-Relational Mapping: a mapping between Java objects and relational database tables. In Java you work with objects, fields, references, and classes. In a relational database you work with tables, rows, columns, primary keys, and foreign keys. ORM describes how those two worlds correspond.
For example, a User class can be mapped to a users table. One User object represents one row. The email field maps to the email column. A relation from Order to User maps to a foreign key such as user_id. The ORM provider uses this mapping to generate SQL and to convert rows back into objects.
ORM has clear benefits: less boilerplate, a more natural object-oriented model, automatic change tracking, repository abstractions, and convenient transaction integration. It also has costs. Generated SQL can be inefficient when the mapping or query is wrong. Lazy loading can surprise beginners. Complex reports or bulk operations may be better expressed directly in SQL. ORM is a tool, not a replacement for database knowledge.
JPA, Hibernate, and the application layers
JPA is a specification, not the library that directly talks to the database. It is a standard set of annotations and interfaces for persistence in Java. A specification defines rules, but it does not perform database work by itself. JPA defines concepts such as @Entity, EntityManager, Persistence Context, entity lifecycle states, and JPQL.
Hibernate is a JPA implementation. It reads JPA annotations, builds metadata about mappings, tracks managed entities, generates SQL, sends SQL through JDBC, and converts database rows into Java objects. In many Spring Boot applications, developers say "JPA" when the actual runtime provider is Hibernate.
| If you write this code | Who handles the work | What actually happens |
|---|---|---|
repository.save(user) | Spring Data JPA delegates to JPA | Your service calls a repository method instead of building an insert manually. |
Entity mapping uses @Entity and @Column | JPA defines the rules | The annotations describe how the Java class corresponds to a table and columns. |
| Runtime needs real SQL | Hibernate executes the mapping | Hibernate reads the JPA metadata and generates SQL for the configured database. |
| SQL reaches PostgreSQL | JDBC carries the request | Hibernate still uses JDBC underneath to send SQL and receive result rows. |
| The row must become a Java object | Hibernate hydrates the entity | Values from the result set are copied into entity fields and tracked in Persistence Context. |
In a typical Spring Boot architecture, the controller receives an HTTP request, the service coordinates the business operation, the repository loads or saves entities, Hibernate executes SQL, and the database stores rows. This separation matters because the controller should not contain database details, and the repository should not contain business rules.
How JPA works at runtime
The EntityManager is the main JPA interface for working with entities. It can persist a new object, find an object by id, remove an object, and create queries. Spring Data JPA often hides direct EntityManager usage behind repositories, but the concept still matters because repositories delegate to JPA internally.
Persistence Context is the working area where JPA keeps managed entities. If an entity is managed, Hibernate knows it and can track changes. When a transaction commits, Hibernate compares current field values with the loaded state and generates SQL updates if needed. This is why a service method can load an entity, change a field, and rely on transaction commit to flush the change.
Entity lifecycle has several basic states. A new object created with new is transient. After saving or loading inside a persistence context, it becomes managed. After the context closes, it becomes detached. A removed entity is scheduled for deletion. Understanding these states prevents confusion about why some object changes reach the database and others do not.
Practice
For practice, create a Spring Boot project with Spring Web, Spring Data JPA, PostgreSQL Driver, and Validation. Start PostgreSQL locally or through Docker. Configure spring.datasource.url, spring.datasource.username, and spring.datasource.password. Enable SQL logging while learning with spring.jpa.show-sql=true. Then create a minimal entity and repository and start the application. If the connection works, Hibernate will initialize the JPA infrastructure and the application will be ready for entity mapping.
Understanding checklist
- I can explain why a database is needed beyond Java memory.
- I understand what JDBC does and why raw JDBC becomes repetitive.
- I can define ORM and name both its benefits and risks.
- I know that JPA is a specification and Hibernate is an implementation.
- I can describe the controller-service-repository-database flow.