What Is CRUD? Create, Read, Update, Delete

Every database-backed application does four things to its data and nothing else. It creates a record, reads a record, changes a record, or removes a record. A user signs up: create. They log in and load their profile: read. They change their address: update. They close the account: delete. Behind the buttons and the API calls, those four verbs cover the entire lifecycle of a row in a table. The acronym for them is CRUD: Create, Read, Update, Delete.

CRUD is not a framework or a product. It is a model, a way of naming the operations that persistent storage has to support to be useful at all. It shows up in SQL statements, in REST endpoints, in ORM method names, and in the database audit logs a defender reads after an incident. This guide covers what CRUD is, what each operation does, how it maps to SQL and to HTTP, the difference between a hard delete and a soft delete, and why the four operations are a security boundary, not just a developer convenience. It is written for the people who have to reason about data access under pressure: SOC analysts triaging a suspicious query, threat hunters baselining database activity, DFIR responders reconstructing what an attacker did to a table.

What is CRUD?

CRUD is the acronym for Create, Read, Update, and Delete, the four operations that manage persistent data in a datastore. Persistent means the data outlives the request that touched it: it is written to disk in a relational database like PostgreSQL or MySQL, or a NoSQL database like MongoDB or DynamoDB, and it is still there on the next request. The four operations are the complete set of things you can do to that stored data. You can add new data, retrieve existing data, change existing data, or remove existing data. There is no fifth verb.

That completeness is the reason the model is useful. If a system exposes all four operations on a resource, it gives you full lifecycle control over that resource. If it deliberately exposes only some of them, that is a design decision with security weight. A logging table should accept Create but not Update or Delete, because tamper-evident logs are append-only. A read replica should serve Read and reject the other three. A reporting account should hold Read alone. CRUD is the vocabulary you use to describe and enforce those limits.

The model is also datastore-agnostic. The same four operations describe a relational table, a NoSQL document collection, a key-value store, and an object bucket. The syntax differs in each, but the operation behind the syntax is one of the same four every time. That is why CRUD is the first thing you learn about a new datastore and the last thing that changes.

The four operations

Each operation has a clear job, a typical SQL statement, and a failure mode worth knowing.

Create

Create adds a new record to the datastore. In SQL, that is an INSERT statement. In MongoDB it is db.collection.insertOne() or insertMany(). A user registration, a new order, a fresh log entry: each is a Create. The operation usually returns the identifier of the new record so the application can reference it later.

The security note on Create is that it is where untrusted input first lands in storage. An INSERT built by concatenating user input is the classic SQL injection vector, and stored cross-site scripting begins with a Create that writes an attacker's script into a field that is later read back unescaped. The defense is parameterized queries and input validation at the moment of Create, not later.

Read

Read returns records from the datastore that match some criteria. In SQL it is SELECT. In MongoDB it is db.collection.find(). Read is the highest-volume operation in almost every application, because a single page load can trigger dozens of reads and only an occasional write.

Read is also the operation attackers want most, because data theft is a Read at scale. A breach is rarely an exotic exploit; it is often a legitimate-looking SELECT run by a compromised account against a table it was never meant to touch. That is why a Read of an entire user table by an account that normally reads ten rows is a detection opportunity, and why row counts and result sizes belong in your database telemetry.

Update

Update modifies an existing record. In SQL it is UPDATE. In MongoDB it is db.collection.updateOne() or updateMany(). An Update without a WHERE clause changes every row in the table, which is both a common production accident and a deliberate sabotage technique. The same is true of a NoSQL update with an empty filter.

Update is the operation that quietly rewrites history. An attacker who can Update can change an account's email to hijack password resets, flip a permissions flag to escalate, or alter a transaction record to cover a theft. Unlike a Delete, an Update can leave the row present and plausible while changing what it says, which makes it harder to notice than an outright removal.

Delete

Delete removes a record. In SQL it is DELETE. In MongoDB it is db.collection.deleteOne() or deleteMany(). Like Update, a Delete with no WHERE clause empties the table.

Delete splits into two kinds that matter enormously for an investigation. A hard delete removes the record from storage entirely; the row is gone. A soft delete leaves the row in place and sets a flag (a deleted_at timestamp or an is_deleted column) so the application treats it as gone while the data survives. Soft delete is common precisely because hard-deleted data is hard to recover and impossible to investigate. For a defender, the distinction is the difference between an attacker who erased evidence and one who only hid it. If the application soft-deletes, the attacker's actions may still be sitting in the table under a flag.

How CRUD maps to SQL and HTTP

CRUD is an abstract model, so it gets implemented through whatever interface the system speaks. Two mappings come up constantly: CRUD to SQL, and CRUD to the HTTP methods a REST API uses. Knowing both lets you translate between a web request you see in an access log and the database operation it triggers.

The HTTP mapping is a convention, not a law. REST is a broader architectural style, and the relationship between CRUD and REST has enough nuance that it deserves its own treatment; the short version is that not every REST endpoint is a thin wrapper over a database operation, and PUT versus PATCH carries a real semantic difference (replace the whole resource versus modify part of it). What matters here is the safety property the methods are supposed to have. GET is meant to be safe: a Read that changes nothing. POST, PUT, PATCH, and DELETE are the ones that change state. A GET request that mutates data, or a state-changing action reachable by a simple link, is a design smell and often a vulnerability.

For a defender, the mapping is a translation table. A spike of DELETE requests in a web access log corresponds to records leaving a table. A POST to an unexpected endpoint may be a Create writing attacker data. Reading server logs and database logs together, with the CRUD model as the bridge, is what turns scattered entries into a sequence of actions.

Why CRUD is a security boundary

CRUD is usually taught as a developer's checklist. For a defender it is an access-control model. Permissions in real systems are defined in CRUD terms: this role can Read and Create but not Update or Delete; that service account can Read one schema and nothing else. Mapping every account and role to the specific operations it is allowed on each resource is how you enforce least privilege at the data layer, and it is exactly the granularity that access control is meant to provide.

The boundary shows up three ways in practice.

The permission matrix. Write out which principals can perform which of the four operations on which tables. The gaps are the policy. An application account with Delete on the audit table is a finding, not a feature, because it means the records of an intrusion can be erased by the same credentials that carried it out.

The audit trail. A serious datastore records the CRUD operations performed against it: who ran which statement, against which object, when. Database audit logs and the application logs above them are where you see the Update that changed a permissions flag or the Read that pulled the whole customer table. Without that trail, a clean Update is invisible after the fact. The first question after a database incident is whether CRUD auditing was even enabled, because if it was not, the operations left no record.

The asymmetry of the operations. The four are not equally dangerous. Read at scale is exfiltration. Update is silent tampering. Delete is destruction or evidence removal. Create is the injection point. A monitoring strategy that treats all four the same wastes attention; one that weights them by impact catches the operations that matter. A single Update to a privileges column deserves more scrutiny than a thousand routine Reads.

The takeaway is that the same four operations a developer uses to build features are the four a defender uses to reason about who can do what to the data, and to detect when someone did something they should not have.

Frequently Asked Questions

What does CRUD stand for?

CRUD stands for Create, Read, Update, and Delete. These are the four basic operations for managing persistent data in a datastore such as a relational or NoSQL database. Create adds a record, Read retrieves records, Update modifies a record, and Delete removes a record. Together they cover the full lifecycle of stored data.

How does CRUD map to SQL?

Each CRUD operation maps to a SQL statement: Create is INSERT, Read is SELECT, Update is UPDATE, and Delete is DELETE. The same operations apply to NoSQL databases with different syntax, for example MongoDB uses insertOne(), find(), updateOne(), and deleteOne(). The operation is the same in every datastore even when the command is not.

How does CRUD relate to REST and HTTP methods?

The common convention maps Create to POST, Read to GET, Update to PUT or PATCH, and Delete to DELETE. This is a useful default but not a strict rule, because REST is a broader architectural style and not every endpoint is a direct database operation. The key safety property is that GET should not change data, while POST, PUT, PATCH, and DELETE are the state-changing methods.

What is the difference between a hard delete and a soft delete?

A hard delete removes a record from the datastore entirely, so the data is gone. A soft delete leaves the record in place and sets a flag, such as a deleted_at timestamp, so the application treats it as deleted while the data is retained. Soft delete makes recovery and investigation possible, which matters when you need to determine what an attacker removed.

Why does CRUD matter for security?

Permissions are defined in CRUD terms, so the model is an access-control boundary. Limiting an account to specific operations on specific resources is how you enforce least privilege at the data layer, for example allowing Read but denying Delete on an audit table. Database audit logs record CRUD operations, which is how a defender reconstructs an intrusion. The four operations also differ in risk: Read at scale is exfiltration, Update is silent tampering, and Delete is destruction.

Is every CRUD operation equally risky?

No. The four operations carry different impact. Read at scale is how data is stolen, Update can silently rewrite records like a permissions flag or an email used for password resets, Delete destroys data or removes evidence, and Create is where untrusted input first enters storage and enables injection. A monitoring strategy should weight the operations by impact rather than treating them identically.

The bottom line

CRUD is the four operations every datastore has to support: Create, Read, Update, Delete. Create adds a record, Read retrieves one, Update changes one, Delete removes one, and there is no fifth verb. They map to INSERT, SELECT, UPDATE, and DELETE in SQL and, by convention, to POST, GET, PUT/PATCH, and DELETE over HTTP.

For a defender the model is more than developer shorthand. It is the language of data-layer permissions, the structure of a database audit trail, and a risk lens that separates a routine Read from an exfiltration, a clean Update from tampering, and a Delete from evidence destruction. Know which accounts can perform which of the four operations on which resources, confirm the audit log records them, and you can answer the only question that matters after a database incident: who did what to the data, and when.