Ditching Raw SQL for Spring Data JPA

I used to think using Spring Data JPA meant I didn’t really need to worry about SQL anymore. It felt too easy. 😅 I remember building a feature that looked perfectly fine in code, clean repositories, simple method names, everything “just worked.” Until I started testing it with more data and suddenly the API got slower… and slower. 🐢 Not crashing. Not failing. Just… slower. I opened the logs and saw a flood of queries. One for users, then one for each user’s orders. 📄📄📄 That’s when it hit me, I had no idea what queries were actually running behind my code. That moment was a bit uncomfortable everything “worked”, but I clearly didn’t understand what was happening. 😬 A few things became very real after that: JPA hides complexity, but it doesn’t remove it 🎭 JPA makes things easy, but it doesn’t make database behavior go away ⚠️ Just because you didn’t write the query doesn’t mean it’s efficient. You still need to understand what’s being generated 🔍 Lazy vs eager loading isn’t just theory, it directly impacts performance ⚙️ That innocent looking repository method? It can cause an N+1 problem real quick 🚨 In real systems, this doesn’t show up during basic testing. It shows up as slow endpoints, high DB usage and confusing debugging sessions. 🧩 Now, I still use JPA the same way but I don’t trust it blindly. I check queries, think about fetching strategies and pay attention to what’s happening underneath. 👨💻 What I learned: If you’re using JPA without understanding the queries, you are debugging in the dark. Have you ever been surprised by what JPA was doing behind the scenes? 🤔 #Java #SoftwareEngineer #SpringMVC #SpringBoot #SpringDataJPA

🔥 Day 41 of My Spring Boot Journey Today I explored some powerful features of Spring Data JPA that can significantly optimize database operations 📌 What I learned: ✅ Static Projection → Fetch only required fields using interface-based projections ✅ Dynamic Projection → Create flexible queries where the result type can be decided at runtime ✅ Custom Queries (JPQL & Native SQL) → Write optimized queries using @Query → Use @Param for named parameters → Perform UPDATE & INSERT using @Modifying and @Transactional 💡 Key takeaway: Instead of fetching entire entities, projections help improve performance and make APIs more efficient. Also understood the difference between: 🔹 SQL → works on tables 🔹 JPQL → works on entity classes 📁 Implemented all concepts with hands-on projects including: ✔ Static Projection ✔ Dynamic Projection ✔ Custom Queries Big thanks to my mentor for simplifying these advanced concepts 🙌 #SpringBoot #Java #BackendDevelopment #JPA #Hibernate #LearningInPublic #100DaysOfCode Hyder Abbas

🚀 Spring Data JPA: Simplifying Database Access When building backend applications, handling databases can quickly become painful (SQL, mapping, boilerplate code...). 👉 That’s where Spring Data JPA makes a real difference. 🔹 What is it? Spring Data JPA is an abstraction that allows you to interact with your database using Java objects, based on the ORM (Object-Relational Mapping) concept. 🔹 How does it work? Define entities (@Entity) that map to database tables Create repositories (interfaces) Let Spring automatically generate SQL queries ➡️ Result: less code, more productivity. 🔹 Simple example: @Entity public class User { @Id @GeneratedValue private Long id; private String name; } public interface UserRepository extends JpaRepository<User, Long> { List<User> findByName(String name); } 🔥 With just one line, you can fetch data without writing any SQL. 💡 Why use it? ✔ Huge time saver ✔ Cleaner code ✔ Easier maintenance ✔ Perfect for modern applications 📌 In short: Spring Data JPA lets you focus on business logic instead of database plumbing. #Java #SpringBoot #JPA #Backend #SoftwareEngineering

I read two JetBrains articles recently that seem to completely contradict each other. One says: ❌ don't use data classes for entities in Kotlin. The other says: ✅ data classes are a great fit for entities. Same company. Opposite advice. The difference? One is about JPA. The other is about Spring Data JDBC. Here's why it matters. ── Spring Data JPA (Hibernate) manages entities as tracked, mutable objects. To do that, it needs to: → create proxy subclasses for lazy loading (class must be non-final) → call a no-arg constructor when loading from DB → inject fields via reflection after construction (fields must be mutable) Kotlin's data class breaks all three of these. Final. Immutable. No no-arg constructor. ── Spring Data JDBC is a completely different philosophy. No dirty checking. No proxies. No lazy loading. You call save() → SQL runs. You call findById() → result maps to your object. That's it. And because it uses constructor-based mapping, data classes are a natural fit. Immutable val fields? Great. final class? No problem. copy() to update instead of mutation? That's exactly the pattern. ── So "don't use data classes for entities" really means "...when using JPA." It's not a rule about Kotlin + databases in general. The two frameworks look similar from the outside — both are Spring Data, both talk to relational DBs. But they have fundamentally different models for how objects and databases interact. Once you see that, the contradiction disappears. 📝 Wrote a full breakdown on Medium — link in the comments. #Kotlin #SpringBoot #SpringData #JPA #Backend

🚀 Spring Boot + Database Views & Stored Procedures (Hands-on) Recently, I worked on a backend project where I implemented Database Views and Stored Procedures using Spring Data JPA. 💡 What I built: ✔ Fetched data using database Views (user_view, user_department_view) ✔ Used Stored Procedures (GetUsersBySalary, GetUsersByDepartment) ✔ Wrote native SQL queries with @Query ✔ Mapped results to DTOs for clean API responses ✔ Handled JOINs at database level instead of Java 🔥 Key Learning: Working closer to the database helps in building more optimized and scalable backend systems. 💬 This project helped me understand how real-world applications handle data efficiently using DB-level logic instead of overloading the backend. Open to feedback & suggestions 🚀 git repo: https://lnkd.in/dQ92fr3Z #SpringBoot #Java #JPA #Hibernate #MySQL #BackendDevelopment #SoftwareEngineering #StoredProcedure #DatabaseDesign #APIs #LearningByDoing

𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗤𝘂𝗲𝗿𝘆 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲 Mastering database queries with Spring Boot + JPA In real-world applications, the efficiency of your system often depends on how well you write database queries. While basic CRUD operations are simple, production systems require much more like efficient filtering, optimized joins, aggregations, and handling complex query scenarios. I built this microservice to demonstrate how modern backend systems handle basic to advanced querying patterns using Spring Boot and JPA. Source code: https://lnkd.in/g9b78BnS This project focuses on writing clean, efficient, and scalable queries which something every backend developer should master. 𝗛𝗶𝗴𝗵𝗹𝗶𝗴𝗵𝘁𝘀 • Real-world query scenarios exposed via REST APIs • Performance-focused design (N+1 problem and optimization) • Combination of JPA, JPQL, and native SQL • Practical handling of relational data • Clean and maintainable architecture 𝗪𝗵𝗮𝘁’𝘀 𝗖𝗼𝘃𝗲𝗿𝗲𝗱 • Derived queries (method name-based) • Pagination and sorting for large datasets • Search using LIKE queries • Join queries and fetch join optimization • N+1 problem and its solution • Aggregations (count, sum, group by) • Native SQL queries • Dynamic queries using Specification API • Projections (interface and DTO-based) • Subqueries (average, max, nested queries) • Exists / Not Exists queries • Window functions (ranking, top-N queries, running totals) • Indexed queries for performance • Relationship handling (one-to-many, many-to-many) • Soft delete implementation • Stored procedure integration 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗠𝗮𝘁𝘁𝗲𝗿𝘀 Poorly written queries quickly become a bottleneck: • Slow APIs • High database load • Increased latency • Scalability limitations This project demonstrates how to avoid these issues using proper query design and optimization techniques. 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸 • Java 21 • Spring Boot (REST APIs) • Spring Data JPA (Hibernate) • PostgreSQL • Lombok • Maven This project is useful for developers who want to: • Improve their JPA and SQL skills • Understand real-world query patterns • Learn performance optimization techniques "Efficient queries are the foundation of high-performance systems." #Java #SpringBoot #JPA #Hibernate #SQL #Database #BackendDevelopment #Microservices #Performance #SystemDesign #SoftwareEngineering

"How do you handle slow database queries in Spring Boot?" This comes up in almost every backend interview Most developers jump straight to indexing But that is only part of the answer The real question is why is the query slow in the first place Common causes N+1 queries hitting the database repeatedly Fetching more data than needed Missing pagination on large datasets Wrong fetch type EAGER instead of LAZY Before adding indexes check these Use @Query with JOIN FETCH to avoid N+1 Select only the fields you need not the entire entity Add pagination with Pageable for large results Set fetch = FetchType LAZY and load relations only when needed Indexes help but fixing the query design helps more What database optimization has saved you the most time #Java #SpringBoot #Database #BackendDevelopment #Optimization

ORM vs Raw SQL — Which one should YOU use? Two ways to talk to a database. Both powerful. Both have trade-offs. ORM (Object Relational Mapping) → You write code using models & methods → The ORM layer auto-generates the SQL → Returns hydrated model objects ✅ Faster development, less code, database agnostic ⚠️ But adds overhead & less control on complex queries Raw SQL → You write the exact SQL query → App sends it directly to the database → Returns raw rows ✅ Full control, better performance, ideal for complex joins & aggregations ⚠️ But requires SQL knowledge & more verbose code 🔑 Key Tradeoff: | | ORM | Raw SQL | |---|---|---| | Dev Speed | ⚡ High | Lower | | Query Control | Limited | Full | | Best For | CRUD & Rapid Dev | Complex Queries | 💡 My take: Use ORM for 80% of your daily CRUD work. Switch to Raw SQL when performance matters or queries get complex. In Spring Boot? Spring Data JPA = ORM, JdbcTemplate / Native Queries = Raw SQL. Best devs know when to use which! 🚀 #Java #SpringBoot #SQL #ORM #JPA #BackendDevelopment #DatabaseDesign #SoftwareEngineering

🚀 Spring Data JPA – Simplifying Employee Data Persistence Recently, I built a simple project using Spring Data JPA to understand how efficiently it handles database operations with minimal effort. 💡 Project Overview: This application stores employee details (name and salary) into a MySQL database with very little code and zero manual SQL. 🔹 How It Works (Step-by-Step): 1️⃣ Main Class (App.java) Initializes the Spring container using ApplicationContext Fetches the repository bean Creates an Employee object Saves data using repository.save() 👉 No need to write SQL queries manually 2️⃣ Entity Class (Employee.java) Represents the database table structure Uses key annotations: @Entity → Defines the class as a database table @Id → Specifies the primary key @GeneratedValue → Automatically generates the ID 3️⃣ Repository Interface Extends JpaRepository Provides ready-to-use methods like: save() ✨ Eliminates the need for boilerplate implementation code 4️⃣ Spring Configuration (XML) Handles: MySQL database connectivity JPA and Hibernate setup Entity scanning Transaction management 5️⃣ Maven Dependencies Includes essential libraries: Spring Core & Context Hibernate Spring Data JPA MySQL Connector 🎯 Key Benefit: Spring Data JPA significantly reduces boilerplate code and streamlines database operations, making development faster and cleaner. #SpringBoot #Java #SpringDataJPA #Hibernate #BackendDevelopment  Thanks to Anand Kumar Buddarapu Sir.

🚀 Spring Data JPA – Simple Employee Save Example I recently worked on a basic Spring Data JPA project to understand how database operations can be simplified using Spring. 💡 What this project does: It saves employee details (name & salary) into a MySQL database using very minimal code. 🔹 How it works (Step-by-step): 1️⃣ Main Class (App.java) Loads Spring configuration using ApplicationContext Gets the repository bean Creates an Employee object Saves data using repository.save() 👉 No SQL queries needed! 2️⃣ Entity Class (Employee.java) Represents a database table Uses annotations like: @Entity → marks it as a table @Id → primary key @GeneratedValue → auto-generates ID 3️⃣ Repository Interface Extends JpaRepository Provides built-in methods like: save() ✨ No need to write implementation code! 4️⃣ Spring Configuration (XML) Configures: Database connection (MySQL) JPA & Hibernate Entity scanning Transaction management 5️⃣ Maven Dependencies Spring Core & Context Hibernate Spring Data JPA MySQL Connector 🎯Key Advantage: Spring Data JPA reduces boilerplate code and makes database operations fast, clean, and easy to manage. 📌 Output: When you run the application, a new employee record is automatically inserted into the database. 💬 Final Thought: If you're starting with backend development, Spring Data JPA is a powerful tool to simplify database interactions without writing complex SQL. Thanks to Anand Kumar Buddarapu Sir. #SpringBoot #Java #SpringDataJPA #Hibernate #BackendDevelopment #LearningJourney