What is CRUD (Create, Read, Update, Delete)?

CRUD is a shorthand for create, read, update, and delete — the four basic operations every persistent data store must support. Coined in James Martin’s 1983 Managing the Data-base Environment, it remains the most durable acronym in backend work because it names the floor: whatever else your system does, records must come into being, be found, change, and go away.

Key takeaways

CRUD in Four Languages

-- CRUD as SQL: the original mapping
INSERT INTO tasks (title) VALUES ('Write the launch post');   -- C
SELECT * FROM tasks WHERE done = false;                       -- R
UPDATE tasks SET done = true WHERE id = 42;                   -- U
DELETE FROM tasks WHERE id = 42;                              -- D

And the same cycle as an SDK expresses it — the form most application code actually writes:

// JavaScript / Node.js — Back4app JS SDK
// The full CRUD cycle on one object
const task = new Parse.Object('Task');
task.set('title', 'Write the launch post');            // C — create
await task.save();

const fetched = await new Parse.Query('Task')
  .equalTo('done', false).first();                     // R — read

fetched.set('done', true);                             // U — update
await fetched.save();

await fetched.destroy();                               // D — delete

// Flutter / Dart — Back4app Flutter SDK
// The full CRUD cycle on one object
final task = ParseObject('Task')..set('title', 'Write the launch post');
await task.save();                                     // C — create

final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false);
final fetched = (await query.query()).results!.first;  // R — read

fetched.set('done', true);
await fetched.save();                                  // U — update

await fetched.delete();                                // D — delete

// iOS / Swift — Back4app Swift SDK
// The full CRUD cycle on one object
var task = Task()
task.title = "Write the launch post"
let saved = try await task.save()                      // C — create

let fetched = try await Task.query("done" == false)
  .first()                                             // R — read

var updated = fetched
updated.done = true
_ = try await updated.save()                           // U — update

try await updated.delete()                             // D — delete

// Android / Kotlin — Back4app Android SDK
// The full CRUD cycle on one object
val task = ParseObject("Task").apply {
  put("title", "Write the launch post")
}
task.save()                                            // C — create

val fetched = ParseQuery.getQuery<ParseObject>("Task")
  .whereEqualTo("done", false).first                   // R — read

fetched.put("done", true)
fetched.save()                                         // U — update

fetched.delete()                                       // D — delete

One table to map them all

The six-column mapping no single reference assembles:

Two footnotes from the HTTP spec worth actually knowing: GET is safe (no state change), PUT and DELETE are idempotent (repeat without harm), POST is neither — which is why retry logic treats them differently, and why PUT means “replace whole” while PATCH means “modify part.”

Where CRUD happens

The diagram is also the security reminder: every verb crosses the API layer, which is where permissions and validation belong — a CRUD surface without per-operation access control is a public database with extra steps.

CRUD vs. REST

The practical takeaway: a REST API is frequently a CRUD API wearing HTTP — but “approve invoice” belongs in your API and isn’t a CRUD verb, and CRUD happily exists with no HTTP in sight. The terms cooperate; they don’t compete.

Common use cases

• The CRUD app proper. Admin panels, CMSs, CRMs, inventory, bookings — the majority of business software, honorably.
• Prototyping and MVPs. The four verbs on a handful of classes are the first version of most products.
• Auto-generated APIs. Schema in, CRUD surface out — the modern default that makes the four verbs configuration rather than code, covered fully in the auto-generated APIs entry.
• Admin and support tooling. Visual grids over the same CRUD surface, permissions included.
• The substrate under everything else. Event-sourced and workflow-heavy systems still expose CRUD somewhere — settings, profiles, reference data.

Should every action be CRUD? A decision matrix

The last row is the design smell worth memorizing: when endpoint names drift toward updateStatus, the domain is asking for verbs of its own.

Limitations and trade-offs

• Update destroys history. In-place mutation is CRUD’s defining act and its defining loss — anything needing “what did this look like Tuesday” wants journaling or events.
• Delete is a policy, not a verb. Soft vs. hard delete trades auditability against privacy-regime erasure and query complexity; decide per class, on purpose.
• Concurrency is unpriced. Two updates, last writer wins, first writer’s change silently gone — version fields and conditional saves are the standard antidote.
• List is the fifth verb. Filtering, sorting, and pagination carry most real read traffic and most performance bugs — the reason CRUDL and BREAD exist.
• CRUD APIs can go anemic. A surface that’s only rows-in-rows-out pushes business logic to clients; keep the workflows server-side, next to the data.

CRUD on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its relationship to this article is subtraction: define a class and the entire CRUD matrix above exists at once — REST endpoints per the HTTP column, GraphQL mutations, and the SDK idioms in the code tabs, with class-level permissions gating each verb and beforeSave triggers holding the validation. The four verbs stop being your codebase and become your vocabulary.