What is CRUD and why does it appear in almost all applications?
Published on 2026-10-20 by frfrand
CRUD explicado con ejemplos cotidianos: crear, leer, actualizar y eliminar datos, relación con APIs REST, permisos y errores habituales.
CRUD is an acronym for Create, Read, Update and Delete: create, consult, update and delete information. These are four operations that appear over and over again in applications, databases and administrative systems.
A contact agenda, an online store, a reservation system and a customer panel seem like very different products. But almost all need these four actions on some type of record.
An example with an agenda
Create: you add Ana's contact and save her phone number. Read: you open the agenda to find it. Update: Ana changes her number and you correct the record. Delete: you delete a contact you no longer want to keep.
That is CRUD. You don't need to know how to program to understand it because you use it in applications every day.
The importance lies in that these operations help organize requirements and development decisions. «We need a product manager» means, among other things, defining who can create products, who can view them, what fields they can modify and what happens when deleting them.
Is CRUD the same as SQL?
Not exactly. SQL is a language used to work with relational databases. Its instructions include operations related to CRUD: INSERT creates records, SELECT queries, UPDATE modifies and DELETE deletes.
CRUD describes what types of operations the application needs, not the specific language with which they will be implemented.
You can build a CRUD over PostgreSQL, a document database, or even over files, although each alternative has different limits.
How does it relate to a REST API?
A web API usually offers operations associated with resources. For example, GET /products can query products, POST /products can create one, PATCH /products/42 can modify part of its data, and DELETE /products/42 can request its deletion.
But it is not advisable to confuse HTTP methods and CRUD as if they were universal equivalents. HTTP has its own semantics, and an application may require business actions that do not fit into a simple field edit.
For example, confirming a reservation may require checking availability and making atomic changes. It should not be just a button that writes "confirmed" without validations.
Why is it not enough to just make the four screens?
Because business rules are usually more important than the buttons. In a personal agenda, deleting a contact seems simple. In an accounting application, deleting an invoice could be prohibited or require keeping a history.
Operations also need permissions. A user might be able to read their orders and change an address, but not alter the registered price or consult other people's purchases.
Another common mistake is relying solely on frontend controls. Hiding a "delete" button does not prevent someone from attempting to call an API directly. The backend must verify authorization.
Logical deletion and permanent deletion
It is not always convenient to physically delete a record. Some applications use a status field, a deactivation date, or an archiving mechanism, a practice known as soft delete.
This allows recovering information and maintaining relationships with other records. But it should not become an excuse to keep personal data indefinitely. Every project needs an appropriate retention and deletion policy.
What is validation?
When creating or updating information, the system must check types, lengths, formats, and business conditions.
For example, a price should not accept any text, and a reservation should not allow an impossible date. Errors such as non-existent records and simultaneous modifications by multiple people must also be handled.
In systems with multiple users, it is advisable to consider transactions and concurrency control to avoid overwriting important changes.
When is it not convenient to design everything as CRUD?
When an action represents a complex process —approving a loan, issuing a refund, closing a fiscal year—, modeling only the four basic operations can hide essential rules.
CRUD is a useful starting point for understanding the system, not a mandatory architecture for every behavior.
And in ArduMaker?
When building applications connected to PostgreSQL databases or deploying backends on VPSs managed from ArduMaker, many interfaces need CRUD operations. The platform provides infrastructure; data validation, permissions, and business rules must be programmed correctly.
In short: CRUD organizes basic actions on records. The real work of a professional application lies in deciding who can perform them, under what conditions, and with what consequences.
To expand: HTTP methods according to MDN · What is an API.