DELETE(7)

💅 DELETE(7) — the "yeet that row" page, bestie

okay so real talk: this is the DELETE page from the PostgreSQL 17.11 Documentation, and it's genuinely one of the most satisfying commands in the whole manual. it removes rows. that's it. that's the vibe. 🗑️✨

---

🌸 NAME 🌸

DELETE — delete rows of a table

like, literally. rows go bye. 💀

---

✨ SYNOPSIS ✨

[ WITH [ RECURSIVE ] with_query [, ...] ]
DELETE FROM [ ONLY ] table_name [ * ] [ [ AS ] alias ]
    [ USING from_item [, ...] ]
    [ WHERE condition | WHERE CURRENT OF cursor_name ]
    [ RETURNING { * | output_expression [ [ AS ] output_name ] } [, ...] ]

look at that shape. every bracket is optional, but the drama? mandatory. 💅

---

🦋 DESCRIPTION 🦋

so DELETE deletes the rows that satisfy the WHERE clause, from the table you named. and if there's no WHERE clause at all? it deletes every single row in the table. the result is a valid table that is also completely empty. it's giving "i cleaned my room by throwing everything away." 🫶

💡 Tip: TRUNCATE is the faster mechanism for nuking all the rows from a table. same energy, zoomier.

now, there are two ways to delete rows using info that lives in other tables in the database — bestie, take notes:

• using sub-selects
• specifying additional tables in the USING clause

which technique is more appropriate? depends on the specific circumstances, bestie. there's no universal answer, no cap.

the optional RETURNING clause makes DELETE compute and return value(s) based on each row that actually got deleted. and you can use any expression over the table's columns and/or the columns of other tables mentioned in USING. the syntax of the RETURNING list is identical to the output list of SELECT. ikyk. ⭐

also, permissions check 🔍: you must have the DELETE privilege on the table to delete from it, and the SELECT privilege for any table in the USING clause, or any table whose values are read in the condition. no privilege, no party.

---

🎀 PARAMETERS 🎀

• with_query — the WITH clause lets you specify one or more subqueries that can be referenced by name in the DELETE query. see Section 7.8 and SELECT(7) for the details, i'm not retyping the whole lore 💜
• table_name — the name (optionally schema-qualified) of the table to delete rows from. if ONLY is specified before the table name, matching rows get deleted from the named table only. if ONLY is not specified, matching rows also get deleted from any tables inheriting from the named table. optionally, * can be specified after the table name to explicitly say "yes bestie, descendant tables are included." 👑
• alias — a substitute name for the target table. and when an alias is provided, it completely hides the actual name of the table. like a full rebrand. for example, given DELETE FROM foo AS f, the remainder of the DELETE statement must refer to this table as f, not foo. no deadnaming. 🙈
• from_item — a table expression allowing columns from other tables to appear in the WHERE condition. this uses the same syntax as the FROM clause of a SELECT statement; for example, an alias for the table name can be specified. do not repeat the target table as a from_item unless you wish to set up a self-join (in which case it must appear with an alias in the from_item). don't do it. i'm serious. 💅
• condition — an expression that returns a value of type boolean. only rows for which this expression returns true will be deleted. true = gone. false or null = you live to see another day. 🌈
• cursor_name — the name of the cursor to use in a WHERE CURRENT OF condition. the row to be deleted is the one most recently fetched from this cursor. the cursor must be a non-grouping query on the DELETE's target table. note that WHERE CURRENT OF cannot be specified together with a Boolean condition — it's one or the other, pick a lane. see DECLARE(7) for more on using cursors with WHERE CURRENT OF. 🧚
• output_expression — an expression to be computed and returned by the DELETE command after each row is deleted. it can use any column names of the table named by table_name, or table(s) listed in USING. write * to return all columns. all of them. the whole wardrobe. 🎀
• output_name — a name to use for a returned column. yeah. that's the whole description. slay.

---

🔥 OUTPUTS 🔥

on successful completion, a DELETE command returns a command tag of the form

DELETE count

count is the number of rows deleted. 💀

and here's the important little detail: that number may be less than the number of rows that matched the condition, when deletes were suppressed by a BEFORE DELETE trigger. triggers said "not today." if count is 0, no rows were deleted by the query — and heads up, this is not considered an error. zero is a valid number of rows to delete. we respect it.

if the DELETE command contains a RETURNING clause, the result will be similar to that of a SELECT statement containing the columns and values defined in the RETURNING list, computed over the row(s) deleted by the command. so you get receipts. love that for you. 🧾✨

---

💜 NOTES 💜

PostgreSQL lets you reference columns of other tables in the WHERE condition by specifying those other tables in the USING clause. for example, to delete all films produced by a given producer, one can do:

DELETE FROM films USING producers
  WHERE producer_id = producers.id AND producers.name = 'foo';

what is essentially happening here is a join between films and producers, with all successfully joined films rows being marked for deletion. 🔪

⚠️ this syntax is not standard. it's a PostgreSQL thing. it's iconic, but it's not standard.

a more standard way to do it is:

DELETE FROM films
  WHERE producer_id IN (SELECT id FROM producers WHERE name = 'foo');

in some cases the join style is easier to write or faster to execute than the sub-select style. depends on the circumstances, as established. 🦋

---

⭐ EXAMPLES ⭐

delete all films but musicals — because musicals are safe, they're the main characters:

DELETE FROM films WHERE kind <> 'Musical';

clear the table films — full reset, no thoughts, head empty:

DELETE FROM films;

delete completed tasks, returning full details of the deleted rows:

DELETE FROM tasks WHERE status = 'DONE' RETURNING *;

delete the row of tasks on which the cursor c_tasks is currently positioned:

DELETE FROM tasks WHERE CURRENT OF c_tasks;

and now the big one 👑 — while there is no LIMIT clause for DELETE, it is possible to get a similar effect using the same method described in the documentation of UPDATE:

WITH delete_batch AS (
  SELECT l.ctid FROM user_logs AS l
    WHERE l.status = 'archived'
    ORDER BY l.creation_date
    FOR UPDATE
    LIMIT 10000
)
DELETE FROM user_logs AS dl
  USING delete_batch AS del
  WHERE dl.ctid = del.ctid;

🙈 this use of ctid is only safe because the query is repeatedly run, avoiding the problem of changed ctids. do not run this once and then walk away thinking you're a genius. you're not. i say this with love.

---

🌈 COMPATIBILITY 🌈

this command conforms to the SQL standard — except that the USING and RETURNING clauses are PostgreSQL extensions, as is the ability to use WITH with DELETE. so like, mostly standard. with extra sparkle. ✨

---

🫶 SEE ALSO 🫶

TRUNCATE(7)

---

and that's the whole page, bestie. no notes. 💖

signing off with love from the PostgreSQL 17.11 docs, dated 2026 — DELETE(7) and out. 🎀💅