CRUD Operations: Create, Read, Update, Delete Explained

What is CRUD?

CRUD stands for Create, Read, Update, Delete, the four basic operations you can perform on stored data. A database runs them as SQL statements, a REST API exposes them as HTTP methods, and most admin screens are built around them. If a feature can be described as one of these four verbs, it is CRUD.

How CRUD maps to SQL and HTTP

CRUD example: a users table

The same four operations in SQL:

-- Create
INSERT INTO users (email, name) VALUES ('alice@example.com', 'Alice');
-- Read
SELECT * FROM users WHERE id = 42;
-- Update
UPDATE users SET name = 'Alice Smith' WHERE id = 42;
-- Delete
DELETE FROM users WHERE id = 42;

And as calls to a REST API, where each call hits an API endpoint:

POST   /users        {"email": "alice@example.com", "name": "Alice"}   -> 201 Created, Location: /users/42
GET    /users/42                                                      -> 200 OK
GET    /users?limit=20&offset=0                                       -> 200 OK (a page of users)
PUT    /users/42     {"email": "alice@example.com", "name": "Alice Smith"} -> 200 OK (full replace)
PATCH  /users/42     {"name": "Alice Smith"}                          -> 200 OK (partial change)
DELETE /users/42                                                      -> 204 No Content

PUT vs PATCH

A PUT replaces the whole resource, so the caller sends the full new state. A PATCH is a set of instructions for changing part of it, so the caller sends only the fields that change. Use PATCH for typical edit forms and PUT when the client really holds the complete record.

Which methods are safe to retry?

Per MDN, GET, PUT and DELETE are idempotent: repeating the request leaves the server in the same state. POST and PATCH are not guaranteed to be, so a retried Create can produce a duplicate. Idempotency keys solve that, see idempotency and the HTTP semantics in RFC 9110.

CRUD beyond REST

GraphQL has no per-verb endpoints: reads are queries and writes are mutations. gRPC names its methods after the operation (CreateUser, GetUser). Event-sourced systems record events such as UserCreated instead of overwriting rows. Details in the GraphQL entry.

mutation { createUser(input: {...}) { id } }
query    { user(id: 42) { id name } }
mutation { updateUser(id: 42, input: {...}) { id } }
mutation { deleteUser(id: 42) { success } }

Common CRUD mistakes

• No pagination on list reads. A list endpoint that returns every row slows down and eventually fails as the table grows. See API pagination.
• N+1 queries. The list endpoint runs one extra query per record. Use joins or eager loading.
• Lost updates. Two clients edit the same record and the last write wins. Use an ETag or a version field.
• PUT with a partial body. The server replaces the record and clears every field the caller left out.
• 200 with an empty body for a missing record. Return 404.
• Silent cascade deletes. Deleting a user removes their orders too.
• SQL built from user input. Always use parameterized queries.
• Authorization only on writes. Reads leak data too.

Testing and monitoring CRUD APIs

A CRUD API usually fails under load in the same places: slow list queries, lock contention on updates and duplicate creates on retry. Script a full create, read, update, delete flow and run it with LoadFocus load testing, which runs JMeter and k6 scripts from 25 cloud regions. After release, API monitoring can run a check against your read endpoints (free checks run every 5 minutes) and assert on status code and response body. Related reading: how to load test RESTful APIs and API testing.

FAQ: CRUD operations

Is every API a CRUD API?

Many data APIs map cleanly to CRUD. APIs that run business logic often use other verbs, for example POST /transfers or POST /users/42/send-welcome-email.

What is the difference between CRUD and REST?

CRUD is the set of four operations. REST is an architectural style for APIs that often, but not always, maps those operations onto HTTP methods.

Should I soft delete or hard delete?

Soft delete (setting a deleted_at timestamp) keeps history and can be undone. Hard delete is needed when you must erase data for legal reasons or reclaim storage.

How do I prevent lost updates?

Use optimistic concurrency: the client sends the ETag or version it read, and the server rejects the write if the record has changed since.

Does every model need all four operations?

No. Read-only and append-only resources are fine. Expose only the operations your use case needs.