What Is CRUD? The Four Operations Behind Every App You Build with AI

Why AI Coders Need to Know This

When you ask Claude, Cursor, or Windsurf to "build me a task manager" or "create a blog with an admin panel," the first thing it does is set up CRUD operations. It creates database tables, then writes routes that let users create new records, read existing ones, update them, and delete them. That is the entire backbone of the app.

If you do not understand CRUD, you cannot tell whether the AI gave you a complete app or a half-built one. Did it include a way to update records? Does the delete actually work? Is the read operation going to choke when you have 10,000 rows instead of 10? These are CRUD questions, and they are the difference between an app that works in a demo and an app that works in production.

The good news: CRUD is genuinely simple. It is four operations. Once you see the pattern, you will recognize it everywhere — in every app, every API, every database. It is the single most reusable concept in all of software development.

Think of it like construction. Every building, from a shed to a skyscraper, needs a foundation, walls, a roof, and a door. The materials and complexity change, but those four elements are always there. CRUD is the foundation, walls, roof, and door of software.

Real Scenario

You open Cursor and type:

Build me a task manager app with Express.js and PostgreSQL.

I want to:
- Add new tasks with a title, description, and priority
- See all my tasks in a list
- Mark tasks as complete or change their priority
- Delete tasks I don't need anymore

Use a REST API with proper routes. Add comments explaining
what each route does.

Look at that prompt again. You described four features — and every single one maps directly to a CRUD operation:

• "Add new tasks" → Create — inserting a new row into the database
• "See all my tasks" → Read — querying the database and returning results
• "Mark tasks as complete or change priority" → Update — modifying an existing row
• "Delete tasks I don't need" → Delete — removing a row from the database

This is not a coincidence. This is how every app works. A blog? Create posts, read posts, update posts, delete posts. An online store? Create products, read the catalog, update prices, delete discontinued items. A social media app? Create profiles, read feeds, update bios, delete accounts.

Every feature you can think of is one of these four operations wearing a different hat.

What AI Generated

Here is what Claude or Cursor generates for that task manager prompt — a complete set of CRUD routes using Express.js and PostgreSQL. This is real, working code:

const express = require('express');
const { Pool } = require('pg');

const app = express();
app.use(express.json()); // Parse JSON request bodies

// Connect to PostgreSQL
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

// ============================================
// CREATE — Add a new task
// HTTP Method: POST
// SQL Command: INSERT INTO
// ============================================
app.post('/api/tasks', async (req, res) => {
  try {
    const { title, description, priority } = req.body;

    // INSERT a new row into the tasks table
    // RETURNING * gives us back the created record (including its new id)
    const result = await pool.query(
      `INSERT INTO tasks (title, description, priority)
       VALUES ($1, $2, $3)
       RETURNING *`,
      [title, description, priority || 'medium']
    );

    // 201 = "Created" — the standard status code when a new resource is made
    res.status(201).json(result.rows[0]);
  } catch (error) {
    console.error('Create task failed:', error.message);
    res.status(500).json({ error: 'Failed to create task' });
  }
});

// ============================================
// READ — Get all tasks
// HTTP Method: GET
// SQL Command: SELECT
// ============================================
app.get('/api/tasks', async (req, res) => {
  try {
    // SELECT * gets every column from every row in the tasks table
    // ORDER BY created_at DESC shows newest tasks first
    const result = await pool.query(
      'SELECT * FROM tasks ORDER BY created_at DESC'
    );

    // 200 = "OK" — the standard success response
    res.status(200).json(result.rows);
  } catch (error) {
    console.error('Read tasks failed:', error.message);
    res.status(500).json({ error: 'Failed to fetch tasks' });
  }
});

// ============================================
// READ — Get a single task by ID
// HTTP Method: GET
// SQL Command: SELECT ... WHERE
// ============================================
app.get('/api/tasks/:id', async (req, res) => {
  try {
    const { id } = req.params;

    // WHERE id = $1 filters to just the one task we want
    const result = await pool.query(
      'SELECT * FROM tasks WHERE id = $1',
      [id]
    );

    // If no rows came back, that task does not exist
    if (result.rows.length === 0) {
      return res.status(404).json({ error: 'Task not found' });
    }

    res.status(200).json(result.rows[0]);
  } catch (error) {
    console.error('Read task failed:', error.message);
    res.status(500).json({ error: 'Failed to fetch task' });
  }
});

// ============================================
// UPDATE — Modify an existing task
// HTTP Method: PUT
// SQL Command: UPDATE ... SET ... WHERE
// ============================================
app.put('/api/tasks/:id', async (req, res) => {
  try {
    const { id } = req.params;
    const { title, description, priority, completed } = req.body;

    // UPDATE changes existing data
    // SET assigns new values to the columns we want to change
    // WHERE id = $5 makes sure we only update the one task, not all of them
    // RETURNING * gives us the updated record back
    const result = await pool.query(
      `UPDATE tasks
       SET title = $1, description = $2, priority = $3, completed = $4
       WHERE id = $5
       RETURNING *`,
      [title, description, priority, completed, id]
    );

    if (result.rows.length === 0) {
      return res.status(404).json({ error: 'Task not found' });
    }

    res.status(200).json(result.rows[0]);
  } catch (error) {
    console.error('Update task failed:', error.message);
    res.status(500).json({ error: 'Failed to update task' });
  }
});

// ============================================
// DELETE — Remove a task
// HTTP Method: DELETE
// SQL Command: DELETE FROM ... WHERE
// ============================================
app.delete('/api/tasks/:id', async (req, res) => {
  try {
    const { id } = req.params;

    // DELETE FROM removes the row entirely from the database
    // WHERE id = $1 makes sure we only delete the specific task
    // Without WHERE, this would delete EVERY task — a catastrophic mistake
    const result = await pool.query(
      'DELETE FROM tasks WHERE id = $1 RETURNING *',
      [id]
    );

    if (result.rows.length === 0) {
      return res.status(404).json({ error: 'Task not found' });
    }

    // 200 with the deleted record, so the frontend knows what was removed
    res.status(200).json({ message: 'Task deleted', task: result.rows[0] });
  } catch (error) {
    console.error('Delete task failed:', error.message);
    res.status(500).json({ error: 'Failed to delete task' });
  }
});

app.listen(3000, () => {
  console.log('Task manager API running on port 3000');
});

That is a complete CRUD API. Five routes, four operations. Every task manager, note-taking app, and project board you have ever used runs on code that looks almost exactly like this.

Understanding Each Part

Each CRUD operation connects three layers: an HTTP method (how the frontend talks to the backend), an API route (the URL and logic that handles the request), and a SQL command (how the backend talks to the database). Here is the complete mapping:

CRUD Across the Stack

CRUD is not just a backend concept. It flows through every layer of your application, from the button a user clicks to the row stored in the database. Understanding this flow is how you debug problems — because when something breaks, it broke at one of these layers.

Layer 1: Frontend (What the User Sees)

The frontend is where CRUD operations start. Every user action maps to one:

• Create: A form with a "Submit" or "Add" button. The user fills in fields and clicks submit. The frontend collects the form data and sends a POST request.
• Read: A page loading data on mount. The frontend sends a GET request when the page loads and renders the results into the UI — a list of tasks, a table of products, a feed of posts.
• Update: An "Edit" button that opens a pre-filled form. The user changes fields and clicks "Save." The frontend sends a PUT or PATCH request with the updated values.
• Delete: A "Delete" or "Remove" button (usually with a confirmation dialog). The frontend sends a DELETE request with the record's ID.

// Frontend: Creating a task with fetch()
async function createTask(taskData) {
  const response = await fetch('/api/tasks', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(taskData),
  });

  if (!response.ok) {
    throw new Error(`Create failed: ${response.status}`);
  }

  return response.json(); // returns the new task with its ID
}

// Frontend: Reading all tasks
async function getTasks() {
  const response = await fetch('/api/tasks');
  if (!response.ok) throw new Error(`Read failed: ${response.status}`);
  return response.json(); // returns an array of task objects
}

// Frontend: Updating a task
async function updateTask(id, updates) {
  const response = await fetch(`/api/tasks/${id}`, {
    method: 'PUT',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(updates),
  });

  if (!response.ok) throw new Error(`Update failed: ${response.status}`);
  return response.json();
}

// Frontend: Deleting a task
async function deleteTask(id) {
  const response = await fetch(`/api/tasks/${id}`, {
    method: 'DELETE',
  });

  if (!response.ok) throw new Error(`Delete failed: ${response.status}`);
  return response.json();
}

Layer 2: API Routes (The Middleman)

The API routes sit between the frontend and the database. They receive HTTP requests, validate the data, run the database query, and send back a response. This is exactly the Express.js code we saw in the "What AI Generated" section above.

The API layer is where business logic lives. It is not just a pass-through — it decides whether the user is allowed to perform this operation, whether the data is valid, and what format the response should take.

Layer 3: Database (Where Data Lives)

The database is where CRUD operations actually happen. Every API route translates the request into a SQL query that the database engine executes:

-- CREATE: Add a new task
INSERT INTO tasks (title, description, priority)
VALUES ('Write CRUD article', 'Explain CRUD for vibe coders', 'high');

-- READ: Get all tasks
SELECT * FROM tasks ORDER BY created_at DESC;

-- READ: Get one specific task
SELECT * FROM tasks WHERE id = 42;

-- UPDATE: Change a task's priority
UPDATE tasks SET priority = 'low', completed = true WHERE id = 42;

-- DELETE: Remove a task
DELETE FROM tasks WHERE id = 42;

When you see it laid out like this, the entire stack is just CRUD flowing downhill: user action → HTTP request → API route → SQL query → database row. And the response flows back up: database result → API response → HTTP response → UI update.

The Full Flow in One Picture

User clicks "Add Task"
  → Frontend sends POST /api/tasks with { title, description, priority }
    → Express route receives request, validates data
      → PostgreSQL runs INSERT INTO tasks (...)
        → New row created with id = 43
      → Database returns the new row
    → Express sends response: 201 Created + { id: 43, title: "..." }
  → Frontend receives response
→ UI shows the new task in the list

What AI Gets Wrong About CRUD

AI is great at generating basic CRUD code. It is less great at generating production-ready CRUD code. Here are the gaps you will find most often — and they are the same gaps in almost every AI-generated app.

1. Missing Validation on Create

AI almost always skips input validation. The Create route above accepts whatever the user sends and shoves it straight into the database. What if the title is empty? What if priority is set to "banana"? What if someone sends a million-character description?

// What AI generates (no validation)
app.post('/api/tasks', async (req, res) => {
  const { title, description, priority } = req.body;
  const result = await pool.query(
    'INSERT INTO tasks (title, description, priority) VALUES ($1, $2, $3) RETURNING *',
    [title, description, priority]
  );
  res.status(201).json(result.rows[0]);
});

// What it should generate (with validation)
app.post('/api/tasks', async (req, res) => {
  const { title, description, priority } = req.body;

  // Validate required fields
  if (!title || title.trim().length === 0) {
    return res.status(400).json({ error: 'Title is required' });
  }
  if (title.length > 200) {
    return res.status(400).json({ error: 'Title must be under 200 characters' });
  }

  // Validate allowed values
  const allowedPriorities = ['low', 'medium', 'high'];
  if (priority && !allowedPriorities.includes(priority)) {
    return res.status(400).json({ error: 'Priority must be low, medium, or high' });
  }

  // Now it is safe to insert
  const result = await pool.query(
    'INSERT INTO tasks (title, description, priority) VALUES ($1, $2, $3) RETURNING *',
    [title.trim(), description?.trim() || '', priority || 'medium']
  );
  res.status(201).json(result.rows[0]);
});

Always check AI-generated Create operations for input validation. If you see data going straight from req.body to a SQL query with nothing in between, that is a problem.

2. No Pagination on Read

The Read route above uses SELECT * FROM tasks — which returns every single task in the database. With 10 tasks, that is fine. With 100,000 tasks, that is a performance disaster that could crash your app or your database.

Production Read operations need pagination — returning data in chunks (page 1: tasks 1–20, page 2: tasks 21–40, etc.).

// Paginated Read
app.get('/api/tasks', async (req, res) => {
  const page = parseInt(req.query.page) || 1;
  const limit = parseInt(req.query.limit) || 20;
  const offset = (page - 1) * limit;

  const result = await pool.query(
    'SELECT * FROM tasks ORDER BY created_at DESC LIMIT $1 OFFSET $2',
    [limit, offset]
  );

  // Also return total count so the frontend knows how many pages there are
  const countResult = await pool.query('SELECT COUNT(*) FROM tasks');
  const total = parseInt(countResult.rows[0].count);

  res.json({
    tasks: result.rows,
    pagination: { page, limit, total, pages: Math.ceil(total / limit) }
  });
});

3. Hard Delete Instead of Soft Delete

AI almost always generates hard deletes — DELETE FROM tasks WHERE id = $1. That row is gone. Forever. No undo. No recovery. No audit trail.

Production apps typically use soft deletes: instead of removing the row, you set a deleted_at timestamp. The row stays in the database but is filtered out of normal queries.

// Soft delete instead of hard delete
app.delete('/api/tasks/:id', async (req, res) => {
  const { id } = req.params;

  // Instead of DELETE FROM, update the deleted_at column
  const result = await pool.query(
    'UPDATE tasks SET deleted_at = NOW() WHERE id = $1 AND deleted_at IS NULL RETURNING *',
    [id]
  );

  if (result.rows.length === 0) {
    return res.status(404).json({ error: 'Task not found' });
  }

  res.json({ message: 'Task deleted', task: result.rows[0] });
});

// And update your Read queries to exclude soft-deleted records
// SELECT * FROM tasks WHERE deleted_at IS NULL ORDER BY created_at DESC

4. No Authentication or Authorization Checks

The CRUD routes above let anyone do anything. Any user can read, update, or delete any other user's tasks. There are no authentication checks ("is this person logged in?") and no authorization checks ("is this person allowed to modify this specific record?").

This is the most common security gap in AI-generated code. The AI builds working CRUD, but it builds it wide open.

5. No Error Details in Responses

AI tends to return generic error messages like { error: "Failed to create task" }. In development, you need to know why it failed. Was it a duplicate title? A foreign key constraint? A connection timeout? Good error handling returns enough detail to debug without exposing internal system information.

How to Debug CRUD with AI

When your CRUD operations break — and they will — here is how to diagnose and fix the problem using your AI tools.

Step 1: Identify Which Operation Failed

Every bug in a CRUD app maps to one of the four operations. Ask yourself: "Was I trying to Create, Read, Update, or Delete?" This immediately narrows down the code you need to look at — usually to a single route and a single SQL query.

Step 2: Check the HTTP Response

Open your browser's DevTools (Network tab) or check your terminal output. Look at:

• Status code: 400 = bad input, 404 = wrong URL or missing record, 500 = server error
• Response body: The error message (if the API returns one)
• Request body: What your frontend actually sent (is it what you expected?)

Cursor Tips

• Select the specific CRUD route that is failing and ask: "Why would this route return a 500 error when I send this request body: { title: 'test' }?"
• Ask Cursor to add validation: "Add input validation to this POST route. Check for required fields, string length limits, and valid enum values."
• Ask Cursor to add pagination: "This GET route returns all records. Add cursor-based pagination with a default limit of 20."

Windsurf Tips

• Describe the symptom, not the code: "My app lets me add tasks but when I try to edit one, nothing happens and I don't see any errors." Windsurf is good at tracing through the full stack when given a behavior description.
• Ask Windsurf to generate a test suite: "Write tests for all four CRUD operations on the /api/tasks routes. Test both success cases and error cases (missing fields, invalid IDs, duplicate records)."

Claude Code Tips

• Claude Code can test your routes directly from the terminal: "Test my task API — try creating a task, reading all tasks, updating the first one, and deleting it. Show me the full request and response for each step."
• Ask Claude Code to audit your CRUD routes: "Review my Express routes and tell me what's missing for production readiness. Check for validation, error handling, pagination, auth, and SQL injection protection."
• When your database query fails, paste the exact error. PostgreSQL errors are specific — violates foreign key constraint, column "titl" does not exist, null value in column "title" violates not-null constraint. Claude Code can diagnose these instantly.

What to Learn Next

CRUD is the foundation. Everything else in backend development is built on top of it. Here is where to go next:

• What Is a REST API? — the protocol layer that carries your CRUD operations over HTTP. If CRUD is what you do with data, REST is how you communicate those operations between frontend and backend.
• What Is SQL? — the language behind every CRUD database operation. Understanding SELECT, INSERT, UPDATE, and DELETE at the SQL level lets you read and fix the queries AI generates.
• What Is PostgreSQL? — the database engine running those SQL queries. Learn how to set it up, how tables and schemas work, and how to use psql to inspect your data directly.
• What Is Authentication? — the security layer your CRUD routes need. Without auth, anyone can create, read, update, or delete anyone else's data.
• What Is Middleware? — the pattern Express uses to run code before your CRUD routes. Validation, authentication, logging — they all happen in middleware.

FAQ