CRUD Operations Explained: The Simple Model Behind Almost Every App You Use

What Is CRUD, Really?

When people say CRUD, they literally mean four actions you can do to data: create, read, update, and delete. Think of a record like a row in a table, a document in a collection, or an item in a key-value store.

To create is to add a new record. To read is to fetch an existing record so you can see it. To update is to change some or all of the fields. To delete is to remove the record from active use.

That’s it. No magic. Just four verbs that describe what software does to data all day long.

Once you have these CRUD operations in your head, it becomes a handy mental model for planning features and designing systems. You stop getting overwhelmed by all the screens and buttons, because underneath it all is the same shape.

When you map a feature to CRUD, you can ask clear questions. What are we creating? Where do we read it? What fields can be updated? Do we delete it for real or do we just mark it as removed?

Most functions in software can be broken down into these four operations. And the wild part is we use CRUD constantly without even realizing it.

Why CRUD Shows Up In Almost Every App You Use

Look at Twitter, for example. Tweets are created when you post, they are read every time someone scrolls the timeline, they can be updated if you’re paying Elon for Twitter Blue, and they can be deleted when you say something silly and hope no one screenshotted it.

Microsoft Word is the same story. You create documents, you read and edit them, and you can delete them when you’re done. The toolbar and the icons feel different from a social app, but the operations are identical.

Even your Amazon shopping basket follows the CRUD model. You add items to it, change the quantity, and remove things you don’t want. Behind the scenes, that basket is a resource with records that represent your chosen products.

Once you start looking, you see CRUD everywhere: calendars with events you create and update, notes apps where you add, read, and edit notes, task managers with checklists you can tick off or delete. The interface varies, but the data life cycle repeats.

So it’s actually rare to find an app that isn’t doing CRUD in some form. There are definitely apps that do more, like real-time analytics or heavy compute, but even those still need a place to store configurations, users, and settings, and guess what handles that part.

Bottom line: if you’re using software that lets you view and change information, you’re using CRUD. We just usually call it by the feature name instead of the data action.

CRUD In Databases: SQL, NoSQL, and Key-Value Stores

So how do we actually use CRUD when we’re programming? We apply it the moment we store data. In SQL databases, you can see CRUD show up as specific statements you’ve probably heard of.

CRUD in SQL

Insert is create. Select is read. Update is update. Delete is delete. Very literal, very clean.

When you write SQL for a user table, it looks like this in your head: insert a user when they sign up, select a user when they log in or view their profile, update a user when they change their email, delete a user when they ask to be removed.

There are extra details you will care about, like primary keys, foreign keys, and indexes. Those are there to keep data unique, connect related records, and make reads fast. But the core operations still map to CRUD.

CRUD in NoSQL and Key-Value Stores

It isn’t just relational databases that use the CRUD model. Key-value and document databases do the exact same thing using different names for the functions.

Take Amazon DynamoDB. You will see CRUD operations as PutItem for create, GetItem for read, UpdateItem for update, and DeleteItem for delete. The names are different, the idea is identical.

In a document store like MongoDB, you’ll see insertOne or insertMany, find, updateOne or updateMany, and deleteOne or deleteMany. Same mental model, different syntax.

Why this mapping matters

When you understand CRUD at the storage layer, it gets easier to reason about how your application will behave under load. Reads and writes scale differently. Updates might touch more indexes than you expect. Deletes might cascade or be blocked by constraints.

Knowing the CRUD shape also reduces uncertainty when you choose a data store. You know you’ll need all four operations, so you can check how each database handles them, what the performance looks like, and what patterns are recommended.

CRUD At The API Layer: REST Resources and Endpoints

Storing data is great, but users need a way to access it. That’s where APIs come in. Most of the time when we’re building web apps, we create REST APIs that expose resources.

When people talk about REST, you’ll hear the word resources a lot. That’s just a fancy name for your data. If you’re building a shopping website, your resources are likely to be users, products, orders, and the shopping basket.

In a relational database, each of those resources will be represented by a table. In a document store, each resource might be a collection. Either way, the resource is the thing you are doing CRUD to.

HTTP Verbs Mapped To CRUD

REST leans on HTTP verbs to express CRUD. You’ve seen them before, but here’s the mapping I keep in my head:

• POST - create a new record
• GET - read a record or a list of records
• PUT - update or replace a full record
• PATCH - update part of a record
• DELETE - delete a record

That’s the standard shape. Tools and frameworks expect it. Your future self will thank you for sticking to it.

A Users Endpoint, Painted Clearly

Imagine you’re building a users endpoint. You will have a POST /users endpoint to create a user when they sign up. You will have a GET /users/ {id} to read that user’s details.

You might also have a GET /users for listing users, especially if you have an admin backend. For updates, you can provide PUT /users/ {id} to change the entire record or PATCH /users/ {id} to change specific fields like the display name.

Finally, you will have a DELETE /users/ {id} so you can remove people from your system. That delete is a bit of a funny one, and we’ll talk about why in a second.

Each endpoint maps neatly back to your database operations. POST calls insert or PutItem. GET calls select or GetItem. PUT and PATCH call update or UpdateItem. DELETE calls delete or DeleteItem.

The Tricky Part: Delete Usually Isn’t A Real Delete

Delete on paper sounds simple. In practice, it gets messy fast, especially with relational data and compliance rules.

If you hard-delete a user in a relational database, what happens to their orders, reviews, and payment history? If there are foreign keys, you’ll either need cascade rules or you’ll get errors. And if you care about data integrity, analytics, or regulations, you probably shouldn’t be tossing that history.

That’s why many systems treat delete as a soft delete. You keep the record but mark it as gone using a flag like is_deleted or deleted_at. The record stops showing up in normal reads, but it’s still there for audits, reporting, and potential recovery.

Soft Delete in Practice

On the API side, DELETE /users/ {id} might simply set is_deleted to true. Your list endpoints filter out deleted rows by default. Admin tools might include a toggle to show deleted records for troubleshooting.

In SQL, you might write an update instead of a delete. In DynamoDB, you’ll call UpdateItem to set a field. Same endpoint, different underlying action.

There are tradeoffs. You need to remember to filter out deleted records everywhere. You might need unique constraints that ignore soft-deleted rows. But the upside is huge because you avoid breaking references and you keep your history intact.

When You Must Hard Delete

Compliance sometimes requires true deletion, like specific GDPR requests. In those cases, you design a careful workflow that anonymizes or removes personal data while preserving transactional integrity.

For example, you might scrub email and names but keep order totals for accounting. Or you archive records to a separate store before full removal. Either way, you still start with CRUD and decide how the delete should behave in your domain.

Design Your App From Scratch Using CRUD

If you’re struggling to work out how to build an application from scratch, CRUD gives you a starting line. It forces you to clarify your resources and the exact data you need to store.

Here’s a simple flow I use when I’m sketching a new app:

• List your resources. Users, products, orders, shopping basket, whatever your domain requires.
• Write the fields for each resource. Names, ids, timestamps, status, price, quantity, relationships.
• Decide the CRUD operations you’ll allow for each resource. Who can create? Who can read? What can be updated? What counts as a delete?
• Map those operations to endpoints. One endpoint per CRUD operation per resource keeps things clear.
• Connect each endpoint to the storage layer. Insert or PutItem for create, select or GetItem for read, update for update, delete or soft-delete for delete.
• Build the front end on top of those endpoints. Forms for create and update, lists and detail pages for read, buttons for delete.

When you follow this flow, you end up with a consistent API that mirrors your domain model. The front end can evolve without constantly changing your data shape, and the database stays in lockstep with your endpoints.

All of these endpoints are then used by the front end so real users can interact with your app. Buttons and forms call the API, the API talks to the database, and the database persists the truth.

Concrete Examples: Twitter, Word, and Amazon Through The CRUD Lens

Let’s slow down and walk through the examples because seeing CRUD in familiar apps makes the model click.

Twitter

When you tap the compose button and post, that’s create. The app sends a POST to a tweets resource with the text, metadata, and maybe media references. The backend stores a record in a tweets table or collection.

When you scroll and read tweets, that’s read. GET calls fetch lists and details, with filters like by user or by timeline ranking.

If you’ve got Twitter Blue, you can edit a tweet for a short window. That’s update. The API might call PATCH to change only the text, while logging an edit history behind the scenes.

When you delete a tweet because you changed your mind, that’s delete. Most likely it is soft-deleted for a while so services downstream can catch up and so moderation tools can still see what happened.

Microsoft Word

Creating a document is a fresh record in storage. Reading is opening it. Updating is saving changes or autosave as you type. Deleting is moving it to the recycle bin or actually removing it from disk or the cloud provider.

The UI looks like menus and toolbars instead of endpoints, but under the hood it’s the same four operations working with a file resource.

Amazon Shopping Basket

Adding an item to your basket is create. The API records a basket line item with product id, price, quantity, and timestamps.

Viewing your basket is read. The app calls GET to fetch your current items and totals.

Changing quantity is update. PATCH is perfect for this because you only change the quantity field and maybe the line subtotal.

Removing an item is delete. Some implementations actually delete the line; others mark it removed so they can use it for recommendations or recovery if your session bounces.

How CRUD Shapes Front End Experiences

Even though CRUD sounds backend-y, it drives real UI decisions. Each screen and button maps to an operation, and that helps you design clean flows.

Create maps to forms and wizards. Read maps to lists, tables, and detail pages. Update maps to edit forms and inline editors. Delete maps to confirm dialogs and undo toasts.

On the front end, components wrap these operations with a good user experience. You handle loading states for reads, validation and error messages for creates, optimistic updates so the UI feels snappy, and confirmation flows so deletes aren’t scary.

And because your API is consistent, your front end code can be consistent too. You can reuse list components for any resource and share form logic for create and update.

Common Variations: PUT vs PATCH, Bulk Endpoints, and Lists

Developers always ask about PUT vs PATCH. PUT usually means replace the whole record. PATCH means change only the fields you send.

For example, PUT /users/{id} might require you to send the full user object. PATCH /users/{id} lets you send just { displayName: "New Name" } and leave everything else alone.

Bulk endpoints show up when you need to create or update many records at once. POST /orders/bulk or PATCH /products/bulk is common in admin tools. It’s still CRUD, just multiplied.

Lists come in two flavors: GET /resource for many and GET /resource/ {id} for one. Add filters and pagination to keep reads fast, like GET /orders?status=paid&page=2.

Data Integrity, Compliance, and The Real World

CRUD is simple, but real apps have rules. You might need to prevent deletes that would break reports. You might require updates to pass validation or specific authorization checks.

Compliance can shape CRUD too. Sometimes you have to retain data for a certain period. Sometimes you must permanently erase personal information when asked. Knowing your delete policy upfront saves you from last minute rewrites.

This is why many teams treat delete as an update under the hood. Instead of removing rows, they change a status field. It keeps the model predictable and your reports stable.

And if you truly must remove data, design a clear process: archive what you can, anonymize fields you must, and confirm dependencies are handled before the final hard delete.

Putting It All Together: From Data Model To Working App

Here’s a simple way to go from idea to working app with CRUD guiding you the whole way.

Step 1: Identify Resources

Write down the nouns in your app. Users, sessions, products, orders, baskets. Each noun is a resource that needs CRUD.

Step 2: Define Fields

For each resource, list the fields. Include ids, timestamps, and anything you’ll query by later. Think about uniqueness and relationships early.

Step 3: Choose Storage

Pick SQL if relationships and structured queries are your thing. Pick a key-value or document store if you want flexible shapes and massive scale. It all still maps to CRUD.

Step 4: Draft Endpoints

For every resource, write the endpoints: POST, GET, PUT or PATCH, and DELETE. Keep names consistent. Add list endpoints and filters where needed.

Step 5: Wire The Front End

Build forms for create and update. Build lists and detail views for read. Add a delete button with a confirm flow. Test each operation with realistic data.

Step 6: Add Permissions and Validation

Decide who can call which operations. Validate inputs so updates don’t break assumptions. Return clear errors so the UI can explain what went wrong.

Why This Mental Model Sticks

CRUD is one of those mental models you really need to grasp because it shows up everywhere. It compresses complexity into something your brain can hold while you design features and systems.

When I’m planning a new feature, I literally ask: what’s the resource and what are the CRUD operations we need to support. That question alone gets the team aligned on endpoints, database changes, and UI flows.

And the best part is it scales with you. Start small with a simple table and a couple endpoints. Grow into multiple resources, relationships, and services over time. The verbs stay the same.

Final Thoughts: Master CRUD, Build Anything

You’ve seen how create, read, update, and delete quietly power Twitter, Microsoft Word, and even your Amazon basket. You’ve seen how the same four operations show up in SQL as INSERT, SELECT, UPDATE, DELETE and in REST as POST, GET, PUT or PATCH, and DELETE.

If you’re building from scratch, figure out your resources, list the fields, map the CRUD operations, build the endpoints, and then layer your front end on top. Keep delete practical with soft delete where it makes sense, and be intentional with data integrity and compliance.

Once you have CRUD in your head, you can use it to create any application you want. If you’re new to programming, CRUD is step one, and then you’ll want to dig into data structures and algorithms next so you can make this stuff fast and reliable.

Thanks for reading. If this clicked, keep going with data structures and algorithms next. I’ll see you in the next one.