Have you ever thought about how websites are so dynamic? Where does the data come from? How is it displayed instantly on your screen? How do they allow you to edit and delete information with one click? The questions are many, but the answer is CRUD (Create, Read, Update, and Delete) operations.
CRUD is a standardized system that defines how applications will use data stored in a database. Think of it as a roadmap that tells how data flows through systems from input to storage, editing, retrieving and deleting. These operations are important for the successful daily management of data.
Do you know how it works? No Problem! I have created this blog to explain what CRUD operations are, their application to different technologies, common mistakes, etc. Let's begin with the definition!
CRUD operations are the four basic functions of persistent storage in computer programming and database management. They represent the essential methods for handling data in both relational (SQL) and non-relational (NoSQL) databases. They allow users to add new records, retrieve data, update existing records and delete information.
Understanding its importance will help you know how modern software stays functional, scalable, and reliable. Here are five reasons why they matter:
These four operations provide a structured approach to managing information in databases. By defining clear actions for adding, retrieving, modifying, and removing data, they create consistency across systems and development practices.
User-driven platforms depend on continuous data interaction. Whether someone is registering an account, editing a profile, viewing content, or deleting records, these operations make real-time functionality possible.
From managing inventory in e-commerce to processing transactions in financial systems, these database actions support daily business activities. They ensure that records remain accurate and operations run smoothly.
The ability to update incorrect entries and remove outdated information helps maintain clean and reliable databases. This directly improves reporting accuracy, decision-making, and overall system performance.
Most backend frameworks and RESTful APIs are built around these four actions. HTTP methods like POST, GET, PUT/PATCH, and DELETE are commonly mapped to CRUD operations in REST APIs. This is also why they are fundamental to modern web development.
Database operations are used to manage data efficiently by performing create, read, update, and delete actions that ensure accurate storage, retrieval, modification, and removal of information within an application across various systems. Let me explain this to you with the following example: Employee Management System
Create a Database Table (SQL):
|
This table will store employee records.
SQL Query
|
Python (Flask) Example
|
This creates a new employee record.
SQL Query
|
Python Example
|
This fetches all employee records.
SQL Query
|
Python Example
|
This updates an employee's salary.
SQL Query
|
Python Example
|
This removes the employee record permanently.
Read Also- Java Object-Oriented Programming Concepts Explained with Examples
In REST APIs, it is used to manage data efficiently by enabling Create, Read, Update and Delete operations that ensure seamless communication between clients and servers in web applications and services. In REST APIs, GET, PUT and DELETE are considered idempotent operations, meaning repeated requests produce the same result. POST is not idempotent because it creates new resources. Let me explain this to you with the help of an example: User Management REST API
Now imagine that you are building a simple REST API for managing users.
Base URL:
| https://api.example.com/users |
We use the post method when you have to create a new user.
Request
|
Body
|
Response:
|
To retrieve user information, we use GET.
Get All Users
|
Get a Specific User
|
Response:
|
GET is used only to fetch data (it does not modify anything).
PUT or PATCH is used when you want to update the user's details.
Difference:
Example Using PATCH
|
Body:
|
Response:
|
Update modifies existing data.
To delete a user:
|
Response:
|
Now the data is removed permanently.
An operation is idempotent if calling it multiple times produces the same result as calling it once.
| HTTP Method | CRUD Operation | Idempotent? | Why? |
| GET | READ | Yes | Fetching data never changes it |
| PUT | UPDATE | Yes | Replacing a record with the same data gives the same result |
| DELETE | DELETE | Yes | Deleting an already-deleted record still results in it being gone |
| POST | CREATE | No | Each call creates a new record, so results differ |
| PATCH | UPDATE | Depends | Usually not idempotent if incrementing or modifying partial values |
Example:
When distributed systems and unreliable networks are use, there’s a chance that the same request may be sent multiple times without intending to do so. Documenting the characteristics of different types of requests helps avoid sending duplicate data created by those requests. This reduces potential bugs, and helps ensure data integrity through its unique identification.
Read Also- What is Abstraction in Java? Advantages, Types, and Examples
In microservices architecture, instead of building one big application (monolith), we break the system into small independent services. In many microservices architectures, an API Gateway is used to route client requests to the appropriate services. It also handles authentication, rate limiting, and monitoring. Let's understand it clearly with the help of an e-commerce system example:
Create User
|
Request:
|
Read User
|
Update User
|
Delete User
|
User Service handles everything related to users.
It does NOT directly access the User database.
Instead, it may:
Create Order
|
|
Order Service handles:
There are 2 main ways:
Service A calls Service B directly. For example: Order Service → calls → User Service API
Using message brokers like Kafka and RabbitMQ. For example:
When an order is created → Order Service publishes an event:
|
Example: User Controller
|
Different technologies handle creating, retrieving, updating, and deleting data in their own ways. Let me explain you how popular backend and frontend frameworks implement these operations and what makes each approach unique:
Spring Boot is used to build backend APIs.
How it works-
For example:
|
|
|
Django has a built-in ORM.
Model (models.py)
|
View (views.py)
|
|
Run: python app.py
Install
|
app.js
|
Run:
node app.js
Model
|
Controller
|
Laravel automatically generates CRUD methods:
Frontend does CRUD using API calls.
React:
|
Angular:
Uses services to call APIs and HttpClient.
MongoDB uses collections and documents instead of tables and rows.
|
| Technology | Type | Database Handling | Best For |
|---|---|---|---|
| Spring Boot | Java Backend | JPA/Hibernate | Enterprise apps |
| Django | Python Backend | Built-in ORM | Fast development |
| Flask | Python Backend | Manual setup | Lightweight APIs |
| Express | Node Backend | Flexible | Real-time apps |
| Laravel | PHP Backend | Eloquent ORM | Structured PHP apps |
| React | Frontend | API-based | UI building |
| Angular | Frontend | API-based | Large frontend apps |
| MongoDB | NoSQL Database | Built-in functions | Flexible/document-based apps |
This data-handling operation is the foundation of almost every modern application, from e-commerce websites to banking systems. Let's understand CRUD with real-world examples and code implementation using a simple Node.js + Express example.
In an e-commerce application, admins can add, update, and remove products, while customers can view listings, showcasing practical product management using backend technologies. Let's understand this with an example:
Think of an online store like Amazon.
|
|
|
|
In banks it is used for opening accounts, checking balances, depositing money and closing accounts, illustrating secure and structured financial data management.
Open a new bank account.
|
Check account balance.
|
Deposit money.
|
Close account.
|
With its help, users can create posts, view content, edit their posts and delete them, demonstrating real time data interaction and content management.
The user creates a post.
|
The user sees posts.
|
The user edits a post.
|
The user deletes a post.
|
It demonstrates how to create tables, insert records, retrieve data, update entries and delete rows using SQL queries in a structured relational database environment.
Assume we have a table:
|
Add a new record into the table:
|
This inserts a new user into the database.
Fetch all records:
|
Fetch specific columns:
|
Fetch a specific user:
|
Update a user's email:
This changes the email of the user with ID 1.
|
Delete a specific user:
|
Understanding and optimizing data management operations is important for database performance. As applications grow, it remains consistent, allowing for scalable database management across small to large scale systems.
When several users do CRUD activities at once, databases lock the database to keep data safe from damage.
Exclusive Lock (Write Lock): This lock is applied to a row when it is being updated or deleted. While the lock is present, no other user can either read or write to that row.
Shared Lock (Read Lock): This lock is applied to a row when it is being read. Multiple users can read the row simultaneously.
A real-world scenario would be if 500 users on an e-commerce site simultaneously tried to purchase the last item in stock. If locking were not in place, two users could both read that "1 item left", both try to purchase it, and then the inventory would show -1 as remaining.
Using a transaction with a locking is the solution.
|
FOR UPDATE locks a particular row so that no other transactions can access that particular row until the original transaction completes.
What’s the implication for performance? There are too many concurrent locks in the database, which negatively impacts database speed and performance. Therefore, very large applications will utilize other means such as connection pooling, query optimization, or caching (i.e. Redis) in order to reduce their CRUD load on the database.
Poor implementation can cause security risks, system crashes or incorrect information in the database. Knowing the common errors early helps in building safer and more reliable software systems:
Taking user input directly and storing it in the database without checking it.
Bad Example:
|
Correct Way:
|
You should validate before Create or Update.
Writing SQL queries using string concatenation.
Example malicious input:
|
Bad Example:
|
Correct Way:
|
Prepared statements protect your database.
You should never ignore database errors. For that always use exception handling.
Bad Example:
|
Correct Way:
|
Running multiple queries without transaction control.
Bad Example:
|
Correct Way:
|
You should always verify ownership before Update or Delete.
Bad Example:
|
Correct Way:
|
Securing Database operations is critical because cyberattacks target these data interactions. Following are the best practices that you can apply for the same:
Ensure that only verified users can access the system. For example, if a user wants to update their profile then they must:
Without the authentication, anyone can modify user data.
Restrict actions based on user roles. For example, in an e-commerce app:
|
Never trust user input. Example:
Unsafe query:
If userInput = ' OR 1=1 --
It returns all users.
|
Safe version (Parameterized Query):
|
Always use parameterized queries or ORM tools. Example:
|
Use HTTPS (SSL/TLS encryption). Example:
Wrong way: http://example.com
Right way: https://example.com
Track important CRUD activities.
For example: If 10 failed delete attempts happen in 1 minute then it will trigger alert.
Encrypt sensitive data. Example:
Store:
|
Instead of:
|
Hard Delete permanently removes the record from the database. Once deleted, the data cannot be recovered.
Soft Delete marks the record as deleted using a flag or timestamp but keeps it in the database.
Real-world example: In a payroll system, when an employee leaves the company, you should NOT hard delete their record. Salary history, tax records, and past transactions must still be accessible for compliance and auditing.
Hard Delete:
|
Soft Delete:
|
When reading data, filter out soft-deleted records:
|
When building websites or apps, developers use different methods to manage and exchange data. CRUD, REST and GraphQL are common approaches, with a different purpose and working style.
| Parameters | CRUD | REST | GraphQL |
|---|---|---|---|
| Full Form | Create, Read, Update, Delete | Representational State Transfer | Graph Query Language |
| What It Is | Basic operations you perform on data in a database. | A way to build APIs using HTTP methods. | A modern API query language where the client asks exactly what data it needs. |
| Main Purpose | To manage data (add, view, edit, delete). | To send and receive data between client and server. | To fetch only required data efficiently. |
| Works On | Directly works on the database. | Works on URLs (API endpoints). | Works on queries sent to a single endpoint. |
| Number of Endpoints | Not about endpoints (just DB actions). | Multiple endpoints (like /users, /products). | Usually one endpoint (like /graphql). |
| Data Fetching | Fetch full record. | Server decides what data to send. | Client decides what data to get. |
| Flexibility | Low | Medium | High |
| Best For | Simple database apps. | Most web and mobile apps. | Apps needing complex & specific data (like large apps). |
Developers can implement CRUD operations either by writing raw SQL queries directly or by using an ORM (Object Relational Mapping) tool. Both approaches allow applications to create, retrieve, update and delete data from a database, but they differ in how developers interact with the database layer.
Raw SQL involves writing direct database queries using languages like SQL. This gives developers full control over how data is queried, filtered and manipulated. On the other hand, ORM tools provide a higher level of abstraction where database tables are mapped to objects in programming languages such as Python, Java or Node.js. Instead of writing SQL statements, developers interact with objects and methods.
Modern web frameworks such as Django, Spring Boot and Laravel commonly use ORM tools because they simplify development and reduce the chances of SQL errors. However, raw SQL is still useful when developers need highly optimized queries or advanced database control.
When using raw SQL, developers directly write queries to perform CRUD operations on the database.
Create (Insert Data)
|
Read (Retrieve Data)
|
Update (Modify Data)
|
Delete (Remove Data)
|
Using raw SQL gives developers full control over queries, performance tuning and database structure. However, it requires deeper knowledge of SQL syntax and careful handling to avoid security risks such as SQL injection.
ORM frameworks allow developers to perform CRUD operations using objects instead of writing SQL queries. The ORM automatically converts object operations into SQL statements in the background.
Example: Django ORM
Create
|
Read
|
Update
|
Delete
|
ORM tools automatically generate SQL queries in the background, making development faster and reducing boilerplate code. They also improve security because most ORM frameworks use parameterized queries by default.
| Feature | Raw SQL | ORM |
|---|---|---|
| Development Speed | Slower because queries must be written manually | Faster because CRUD methods are built-in |
| Database Control | Full control over queries | Limited control compared to raw SQL |
| Learning Curve | Requires strong SQL knowledge | Easier for beginners |
| Performance Optimization | Better for complex queries | May generate less optimized queries |
| Security | Requires manual protection against SQL injection | Safer due to built-in query parameterization |
In real-world development, both approaches are often used together. Developers commonly use ORM for standard CRUD operations because it speeds up development, while raw SQL is used for complex queries or performance-critical database operations.
Often, CRUD tests utilize black-box testing; therefore, they take place from an end-user perspective by doing some actions (create, read, update, delete) and verifying there were correct updates made in the database without looking at any internal code. Test cases for each operation:
| Operation | What to Verify |
| CREATE | A new record exists in the DB with the correct values |
| READ | Correct data is returned, no extra/missing fields |
| UPDATE | Only the specified fields changed; others were unchanged |
| DELETE | Record is removed (hard) or flagged (soft) correctly |
The CRUD functionality of most software applications is the basis for developing today’s applications because it allows for the effective creation (creating), retrieval (reading), modification (updating), and deletion (deleting) of data in stores (e.g., databases, APIs) that are distributed or not; all types of data stores (e.g., structured, unstructured), including both SQL and NoSQL databases, as well as various methods through which that data can be exchanged (e.g., via REST APIs and microservices).
Therefore, an understanding of these four operations will also help to understand other operational characteristics (e.g., security best practices, idempotency, and how to test). By using these concepts together, developing scalable and maintainable software systems that support the deployment of digital applications in multiple industries will be possible.
Officially, CRUD includes only four actions: Create, Read, Update and Delete. However, in practical applications, Read is often extended into List, Search and Count, which is why some sources mention seven actions.
CRUD is part of the Data Manipulation Language because it modifies and retrieves data.
The difference between them is that ETL extracts, transforms, and loads bulk data between systems for analytics or migration, whereas CRUD manages individual records inside an application's database.