CRUD stands for Create, Read, Update, and Delete — the four basic operations every data-backed application needs to perform on its records. Almost every app, from a to-do list to an enterprise ERP system, is CRUD underneath a lot of surface complexity: you make new things, you look at things, you change things, and you remove things. Understanding CRUD as a baseline makes it easier to see what a framework, API style, or database is actually giving you beyond it.
What changed in 2026
- Auto-generated CRUD backends (from tools like Supabase, Hasura, and similar platforms) became a default starting point for new projects, turning basic CRUD scaffolding into a solved problem rather than boilerplate to write by hand.
- AI code generation tools got noticeably better at producing full CRUD endpoints from a schema or a plain-language description, shifting developer time toward the non-CRUD parts of an app (business logic, edge cases, permissions).
- GraphQL and REST both matured their CRUD conventions further, with most teams settling on consistent patterns rather than inventing bespoke ones per project.
CRUD mapped to REST and SQL
| CRUD operation |
REST HTTP method |
SQL statement |
| Create |
POST |
INSERT |
| Read |
GET |
SELECT |
| Update |
PUT / PATCH |
UPDATE |
| Delete |
DELETE |
DELETE |
Why CRUD is a useful mental model
Thinking in CRUD terms helps when designing an API or a database schema, because it forces you to ask, for every entity in your system: how does this get created, how is it read (one record vs a list, filtered vs unfiltered), how is it updated (full replace vs partial patch), and how — or whether — it can be deleted. Many real bugs come from an entity that supports create and read but was never designed with a safe update or delete path.
Where CRUD is not enough
Plain CRUD models data as independent records with no memory of how they changed. That is fine for a lot of applications, but it breaks down when you need an audit trail, when multiple operations must succeed or fail together, or when "delete" actually means "archive, do not truly remove." Event-sourced and audit-logged systems layer additional structure on top of, or instead of, direct CRUD, recording what happened rather than just the current state.
Common mistakes
- Treating delete as a hard requirement when the business actually needs soft-delete (an archived flag) for compliance, auditing, or undo support.
- Conflating PUT and PATCH. PUT is meant to replace a full resource; PATCH applies a partial update. Using PUT for partial updates can silently wipe fields the client did not send.
- Skipping validation on update because it was already validated on create, ignoring that update payloads often come from different, less-trusted code paths.
- Building only CRUD when the domain needs behavior. A bank account is not just a row you update; it needs operations like "withdraw" that enforce rules a raw UPDATE statement cannot express.
FAQ
Is CRUD the same as REST?
No. CRUD is a set of operations; REST is an architectural style for exposing those operations (and others) over HTTP. REST APIs commonly map their endpoints to CRUD operations, but REST also covers things like statelessness and resource naming that CRUD does not address.
Does GraphQL replace CRUD?
No, GraphQL is a query language and API style that can expose CRUD-like mutations (create, update, delete) and flexible reads, but the underlying operations are still fundamentally CRUD at the data layer in most applications.
When should I use a CRUD framework or auto-generated backend?
For prototypes, internal tools, and apps where the domain logic really is just data in and data out, auto-generated CRUD saves real time. For domains with meaningful business rules, hand-written logic around the CRUD layer is usually worth the extra effort.
How does CRUD relate to database normalization?
Normalization decisions affect how expensive each CRUD operation is. See normalization vs denormalization for how schema design trades off read speed against update complexity.
Where to go next