There are no items in your cart
Add More
Add More
| Item Details | Price | ||
|---|---|---|---|
Every app you have ever used — from Instagram to your banking app — is quietly running the same four moves on data behind the scenes. Here's exactly what they are, how they map to SQL and REST, and how to build them yourself.
CRUD stands for Create, Read, Update, and Delete — the four basic operations you can perform on any piece of stored data. Whether that data lives in a SQL database, a NoSQL document store, or a simple JSON file, almost every feature you build eventually reduces to one of these four actions.
Think of a spreadsheet. Adding a new row is Create. Opening it to view the data is Read. Editing a cell is Update. Removing the row entirely is Delete. Every backend system, no matter how complex, is built on top of these same four moves — just wrapped in more structure, validation, and security.
Here's what each letter of CRUD means in practice — with the matching HTTP method, SQL statement, and a working code example.
Create is how new records come into existence — a new user signing up, a new product added to a store, a new comment posted under a photo. In SQL this is an INSERT statement; in a REST API it's almost always a POST request.
INSERT INTO users (name, email) VALUES ('Riya Sharma', 'riya@mail.com');
app.post('/users', async (req, res) => { const user = await User.create(req.body); res.status(201).json(user); });
Real-world analogy: filling out a fresh index card and dropping it into the drawer for the first time.
Read is how you fetch data that already exists — your Instagram feed loading, a product page opening, search results appearing. It never changes anything; it only retrieves. SQL uses SELECT, REST APIs use GET.
SELECT id, name, email FROM users WHERE id = 1042;
app.get('/users/:id', async (req, res) => { const user = await User.findById(req.params.id); res.json(user); });
Real-world analogy: pulling a card out of the drawer just to read it — you put it right back, unchanged.
Update changes data that already exists — editing your bio, changing an order's shipping address, marking a task as complete. SQL uses UPDATE; REST APIs use PUT (replace the whole record) or PATCH (change just a few fields).
UPDATE users SET email = 'riya.new@mail.com' WHERE id = 1042;
app.patch('/users/:id', async (req, res) => { const user = await User.findByIdAndUpdate( req.params.id, req.body, { new: true } ); res.json(user); });
Real-world analogy: pulling out the card, crossing out the old phone number, and writing the new one — same card, updated details.
Delete permanently removes a record — deleting a post, cancelling an account, clearing an old notification. SQL uses DELETE; REST APIs use the DELETE method. This is the only operation that should always ask for confirmation first.
DELETE FROM users WHERE id = 1042;
app.delete('/users/:id', async (req, res) => { await User.findByIdAndDelete(req.params.id); res.status(204).send(); });
Real-world analogy: pulling the card out of the drawer for good and shredding it.
This is the table every backend developer eventually memorises. Bookmark it.
| CRUD | SQL Statement | HTTP Method | Typical Endpoint | Success Code |
|---|---|---|---|---|
| Create | INSERT | POST | /users | 201 Created |
| Read | SELECT | GET | /users/:id | 200 OK |
| Update | UPDATE | PUT / PATCH | /users/:id | 200 OK |
| Delete | DELETE | DELETE | /users/:id | 204 No Content |
The four operations stay identical in concept — only the syntax changes depending on the database you're using.
| Operation | SQL (MySQL / PostgreSQL) | NoSQL (MongoDB) |
|---|---|---|
| Create | INSERT INTO table VALUES (...) | db.collection.insertOne({...}) |
| Read | SELECT * FROM table WHERE id=1 | db.collection.findOne({id:1}) |
| Update | UPDATE table SET x=y WHERE id=1 | db.collection.updateOne({id:1},{$set:{x:y}}) |
| Delete | DELETE FROM table WHERE id=1 | db.collection.deleteOne({id:1}) |
Here's the exact order you'd follow to wire up CRUD for a simple "Notes" feature using Express and MongoDB.
Define a Note schema with title and content fields.
Accept new note data from the client and save it to the database.
Let the client fetch all notes, fetch one note, and edit an existing note.
Remove a note permanently once the user confirms they want it gone.
Never trust incoming data. Check required fields, types, and formats before writing anything to the database.
Never return an entire table at once. Use limit and offset (or cursors) so large datasets don't crash the client.
Reserve PUT for full replacements, and PATCH when the client is only changing one or two fields.
For anything valuable, flag a record as deleted: true instead of removing it, so it can be recovered later.
201 for Create, 200 for Read/Update, 204 for Delete — clients rely on these to know what happened.
Check that the requesting user actually owns or is allowed to touch the record before Update or Delete runs.
GET requests should never create, update, or delete anything — browsers and crawlers can trigger them without the user meaning to.
An unchecked Create or Update request is the easiest way to fill your database with broken or malicious data.
Permanently deleting records with no backup means one bad request can wipe out data you can never get back.
A failed database call with no try/catch will crash your server instead of returning a clean error to the client.
No. CRUD is a general pattern for managing any stored data — it applies to databases, but also to files, in-memory caches, and even browser local storage.
PUT replaces the entire resource with the data you send. PATCH updates only the specific fields included in the request, leaving the rest untouched.
Usually yes, in a REST API — each operation maps to its own HTTP method and endpoint. GraphQL APIs handle this differently, using queries for Read and mutations for Create, Update, and Delete.
Because it's irreversible by default. That's why production systems often use soft deletes, confirmation prompts, and strict authorization checks before allowing it.
Launch your Graphy