Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

CRUD

Pattern

A reusable solution you can apply to your work.

Also known as: Create, Read, Update, Delete

Understand This First

  • Database – CRUD operations run against a database.
  • Schema (Database) – the schema defines what CRUD operations can do.
  • Data Model – CRUD operates on the entities defined in the data model.

Context

Once you have a Database and a Schema, you need to actually do things with the data. CRUD is the set of four fundamental operations that cover almost everything an application does to stored entities: Create new records, Read existing ones, Update them, and Delete them. This is an architectural pattern because it provides the vocabulary for how application logic interacts with persistent data. Nearly every API, admin panel, and data layer is organized around these four verbs.

Problem

How do you think about and organize the operations an application performs on its data?

Without a clear framework, data operations proliferate in ad hoc ways. One developer writes an “add user” function, another writes an “insert customer” function, a third writes a “register account” function. All three do essentially the same thing with different names, different validation, and different error handling. The system becomes inconsistent and hard to maintain.

Forces

  • Almost every interaction with stored data fits into one of four categories, but the implementation details vary enormously across contexts.
  • Uniformity (every entity gets the same four operations) makes systems predictable, but not every entity needs all four.
  • Simple CRUD isn’t enough for complex business logic — but it’s the foundation that complex logic builds on.
  • Consistent naming and structure reduce the cognitive load on developers and AI agents alike.

Solution

Organize your data operations around the four CRUD verbs. For each entity in your Data Model, define:

  • Create: How a new instance comes into existence. What fields are required? What defaults apply? What validation runs?
  • Read: How existing instances are retrieved. By ID? By search criteria? With what level of detail?
  • Update: How an existing instance is modified. Which fields can change? What validation applies? What happens to related data?
  • Delete: How an instance is removed. Is it permanently deleted or soft-deleted (marked as inactive)? What happens to related data?

In practice, this often manifests as a set of API endpoints (POST /users, GET /users/:id, PUT /users/:id, DELETE /users/:id) or a set of database functions. The specific technology varies, but the conceptual framework is universal.

Not every entity needs all four operations. Some data is append-only: create and read, but never update or delete, like audit logs. Some data is read-only from the application’s perspective, populated by an external system. Let the domain guide which operations exist.

How It Plays Out

A team building a content management system defines CRUD operations for articles: create (author writes a draft), read (visitors view the article), update (author revises it), and delete (author removes it). This framework structures the entire API, the database layer, and the admin interface. When a new developer joins, they can predict the API shape for any entity because every entity follows the same CRUD pattern.

When directing an AI agent to build a data layer, CRUD is the most effective vocabulary. “Generate CRUD endpoints for the products entity with the following fields and validation rules” is a clear, complete instruction. The agent knows exactly what to produce: four operations with consistent error handling and validation.

Tip

When asking an AI agent to scaffold an application, start with “generate CRUD for these entities” as the foundation. You can add complex business logic afterward, but CRUD gives you a working skeleton immediately.

Example Prompt

“Generate CRUD endpoints for the products entity: create, list, get by ID, update, and delete. Use the field definitions in the schema file. Include input validation and consistent error responses for each operation.”

Consequences

CRUD provides a predictable, universal structure for data operations. New developers (and AI agents) can understand and extend the system quickly because the pattern is widely known. It makes APIs consistent and admin interfaces straightforward to build.

The limitation is that CRUD only covers simple operations on individual entities. Real applications have operations that span multiple entities (“transfer money between accounts”), operations that don’t fit the four verbs (“archive all orders older than a year”), and operations where the business logic is the hard part, not the data access. CRUD is the floor, not the ceiling — but it’s a very useful floor. Complex operations are typically built by composing CRUD operations within Transactions.

  • Uses / Depends on: Database — CRUD operations run against a database.
  • Uses / Depends on: Schema (Database) — the schema defines what CRUD operations can do.
  • Uses / Depends on: Data Model — CRUD operates on the entities defined in the data model.
  • Refined by: Transaction — complex operations compose CRUD within transactions.
  • Refined by: Idempotency — making CRUD operations idempotent is essential for reliable systems.
  • Enables: Consistency — well-designed CRUD operations help maintain data consistency.