RELEASE_SAVEPOINT(7)

✨ RELEASE SAVEPOINT ✨

okay bestie, so this is the RELEASE SAVEPOINT page from the PostgreSQL 18.6 Documentation — it's a section 7 page, so it lives in the SQL commands girlies section 💅

---

🎀 NAME 🎀

RELEASE_SAVEPOINT — release a previously defined savepoint

like... let it go, babe. it served its purpose 🦋

---

🌸 SYNOPSIS 🌸

RELEASE [ SAVEPOINT ] savepoint_name

see that SAVEPOINT in brackets? it's optional, we'll get into that later 🫶

---

💖 DESCRIPTION 💖

RELEASE SAVEPOINT releases the savepoint you named and every active savepoint that got created after it, and it frees up their resources. gone. bye. no crumbs.

Everything you changed since that savepoint was created — the stuff that didn't already get rolled back — gets merged into the transaction (or the savepoint) that was active back when the named savepoint was created. And anything you change after RELEASE SAVEPOINT? Also part of that active transaction or savepoint. it's giving merge era, fr fr 💅

---

🌈 PARAMETERS 🌈

• savepoint_name — the name of the savepoint you wanna release. that's it, that's the whole parameter, we love a low-maintenance icon ✨

---

👑 NOTES 👑

• Naming a savepoint that was never defined? That's an error, bestie. Not a vibe. 💀
• You literally cannot release a savepoint while the transaction is in an aborted state. Not happening. If that's what you're trying to do, you want ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7)) instead. different tool, different job 🧚
• Got multiple savepoints with the same name? Only the most recently defined unreleased one gets released. Keep running the command and it'll work its way through the older ones, one at a time. oldest-last, like a little stack of slay 💜

---

⭐ EXAMPLES ⭐

Wanna make a savepoint and then release it? say less:

BEGIN;
    INSERT INTO table1 VALUES (3);
    SAVEPOINT my_savepoint;
    INSERT INTO table1 VALUES (4);
    RELEASE SAVEPOINT my_savepoint;
COMMIT;

That transaction inserts both 3 and 4. both. no notes. 😌

---

Now a spicier one — multiple nested subtransactions, main character energy:

BEGIN;
    INSERT INTO table1 VALUES (1);
    SAVEPOINT sp1;
    INSERT INTO table1 VALUES (2);
    SAVEPOINT sp2;
    INSERT INTO table1 VALUES (3);
    RELEASE SAVEPOINT sp2;
    INSERT INTO table1 VALUES (4))); -- generates an error

ok so what's happening here: the app asks to release savepoint sp2, which is the one that inserted 3. That changes the insert's transaction context over to sp1. Then the statement trying to insert 4 blows up with an error 😭 — and now the insertions of 2 and 4 are lost, because they're in the same savepoint that just got rolled back, and 3 is sitting in that same transaction context.

At this point the application can only pick one of these two commands, because every other command will just be ignored:

ROLLBACK;
ROLLBACK TO SAVEPOINT sp1;

Pick ROLLBACK and everything dies, including value 1. Pick ROLLBACK TO SAVEPOINT sp1 and value 1 survives, and the transaction gets to keep going 🫶 choose wisely.

---

🦋 COMPATIBILITY 🦋

This command conforms to the SQL standard, periodt. The standard says the key word SAVEPOINT is mandatory — but PostgreSQL is chill and lets you omit it. generous queen behavior honestly 👑

---

💫 SEE ALSO 💫

• BEGIN(7)
• COMMIT(7)
• ROLLBACK(7)
• ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7))
• SAVEPOINT(7)

---

and that's the whole page, bestie!! 🎀✨

PostgreSQL 18.6 · 2026 · RELEASE SAVEPOINT(7) — mwah, go release some savepoints responsibly, ily 💖🌸🫶