CREATE_SEQUENCE(7pg17)

✨ CREATE SEQUENCE ✨

okay so this is the CREATE SEQUENCE(7) page from the PostgreSQL 17.11 docs, and honestly? it's kind of a bop. buckle up bestie, we're making number generators 💅

---

🎀 NAME 🎀

CREATE_SEQUENCE — define a new sequence generator. that's it, that's the whole vibe. it makes numbers go brrr. ✨

---

🦋 SYNOPSIS 🦋

CREATE [ { TEMPORARY | TEMP } | UNLOGGED ] SEQUENCE [ IF NOT EXISTS ] name
    [ AS data_type ]
    [ INCREMENT [ BY ] increment ]
    [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
    [ START [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ]
    [ OWNED BY { table_name.column_name | NONE } ]

---

💖 DESCRIPTION 💖

so CREATE SEQUENCE literally creates a brand-new sequence number generator. the way it works? it makes and initializes a whole new special single-row table with the name name, and the generator is owned by whoever ran the command (main character energy, ngl 👑).

if you give it a schema name, the sequence gets created in that schema. if you don't, it goes in the current schema, easy. temporary sequences live in a special schema, so bestie — you literally cannot give a schema name when you're creating a temporary sequence, that's just not a thing. also, the sequence name has to be distinct from the name of any other relation in that same schema — and by "relation" i mean table, sequence, index, view, materialized view, or foreign table. all of them. 💀

once it exists, you use the functions nextval, currval, and setval to actually work on the sequence. those are documented in Section 9.17, iykyk.

and like — you can't update a sequence directly, but you can run a query like this:

SELECT * FROM name;

to peek at the parameters and current state of a sequence. specifically, the last_value field shows the last value allocated by any session. (obviously that value might already be stale by the time it's printed if other sessions are actively hitting nextval, so don't come for me 🙈)

---

🌸 PARAMETERS 🌸

• TEMPORARY or TEMP — if you say this, the sequence object exists only for this session and gets automatically dropped when the session exits. existing permanent sequences with the same name are not visible in this session while the temporary one exists — unless you reference them with schema-qualified names. sneak peek privileges only 🫶
• UNLOGGED — if you say this, the sequence is created as an unlogged sequence. changes to unlogged sequences are not written to the write-ahead log. they are not crash-safe: an unlogged sequence is automatically reset to its initial state after a crash or unclean shutdown. unlogged sequences are also not replicated to standby servers. 🫠

but like, unlike unlogged tables, unlogged sequences do not offer a significant performance advantage. this option is mainly intended for sequences associated with unlogged tables via identity columns or serial columns. in those cases it usually wouldn't make sense to have the sequence WAL-logged and replicated but not its associated table. make it make sense, right?

• IF NOT EXISTS — do not throw an error if a relation with the same name already exists. a notice gets issued instead. but heads up: there is no guarantee that the existing relation is anything like the sequence that would have been created — it might not even be a sequence 💀 like it could be literally anything. no cap.
• name — the name (optionally schema-qualified) of the sequence to be created. pick something cute.
• data_type — the optional clause AS data_type specifies the data type of the sequence. valid types are smallint, integer, and bigint. bigint is the default. the data type determines the default minimum and maximum values of the sequence. ✨
• increment — the optional clause INCREMENT BY increment specifies which value is added to the current sequence value to create a new value. a positive value makes an ascending sequence, a negative one makes a descending sequence. default is 1. simple as.
• minvalue / NO MINVALUE — the optional clause MINVALUE minvalue determines the minimum value a sequence can generate. if this clause isn't supplied, or NO MINVALUE is specified, then defaults are used. the default for an ascending sequence is 1. the default for a descending sequence is the minimum value of the data type.
• maxvalue / NO MAXVALUE — the optional clause MAXVALUE maxvalue determines the maximum value for the sequence. if this clause isn't supplied, or NO MAXVALUE is specified, then default values are used. the default for an ascending sequence is the maximum value of the data type. the default for a descending sequence is -1.
• start — the optional clause START WITH start lets the sequence begin anywhere it wants, honestly. the default starting value is minvalue for ascending sequences and maxvalue for descending ones.
• cache — the optional clause CACHE cache specifies how many sequence numbers are preallocated and stored in memory for faster access. the minimum value is 1 (only one value can be generated at a time, i.e., no cache), and that's also the default. lowkey the safe choice.
• CYCLE / NO CYCLE — the CYCLE option lets the sequence wrap around when the maxvalue or minvalue has been reached by an ascending or descending sequence respectively. if the limit is reached, the next number generated will be the minvalue or maxvalue, respectively. round and round we go 🎠

if NO CYCLE is specified, any calls to nextval after the sequence has reached its maximum value will return an error. if neither CYCLE nor NO CYCLE are specified, NO CYCLE is the default.

• OWNED BY table_name.column_name / OWNED BY NONE — the OWNED BY option causes the sequence to be associated with a specific table column, such that if that column (or its whole table) is dropped, the sequence gets automatically dropped too. they go down together, ride or die 😭 the specified table must have the same owner and be in the same schema as the sequence. OWNED BY NONE, the default, specifies that there is no such association.

---

💜 NOTES 💜

use DROP SEQUENCE to remove a sequence. bye bestie 👋

sequences are based on bigint arithmetic, so the range cannot exceed the range of an eight-byte integer (-9223372036854775808 to 9223372036854775807). that's the whole range, no exceptions.

because nextval and setval calls are never rolled back, sequence objects cannot be used if you need "gapless" assignment of sequence numbers. it is possible to build gapless assignment by using exclusive locking of a table containing a counter — but that solution is much more expensive than sequence objects, especially if many transactions need sequence numbers concurrently. so like, pick your fighter 💀

unexpected results might be obtained if a cache setting greater than one is used for a sequence object that will be used concurrently by multiple sessions. each session will allocate and cache successive sequence values during one access to the sequence object and increase the sequence object's last_value accordingly. then, the next cache-1 uses of nextval within that session simply return the preallocated values without touching the sequence object. so, any numbers allocated but not used within a session will be lost when that session ends, resulting in "holes" in the sequence. holes! the audacity 🙈

furthermore, although multiple sessions are guaranteed to allocate distinct sequence values, the values might be generated out of sequence when all the sessions are considered. for example, with a cache setting of 10, session A might reserve values 1..10 and return nextval=1, then session B might reserve values 11..20 and return nextval=11 before session A has generated nextval=2. so, with a cache setting of one it is safe to assume that nextval values are generated sequentially; with a cache setting greater than one you should only assume that the nextval values are all distinct, not that they are generated purely sequentially. also, last_value will reflect the latest value reserved by any session, whether or not it has yet been returned by nextval.

another consideration: a setval executed on such a sequence will not be noticed by other sessions until they have used up any preallocated values they have cached. so like, patience bestie 🧚

---

🌈 EXAMPLES 🌈

create an ascending sequence called serial, starting at 101:

CREATE SEQUENCE serial START 101;

select the next number from this sequence:

SELECT nextval('serial');

 nextval
---------
     101

select the next number from this sequence:

SELECT nextval('serial');

 nextval
---------
     102

it's giving consistent. she ate 🔥

use this sequence in an INSERT command:

INSERT INTO distributors VALUES (nextval('serial'), 'nothing');

update the sequence value after a COPY FROM:

BEGIN;
COPY distributors FROM 'input_file';
SELECT setval('serial', max(id)) FROM distributors;
END;

---

⭐ COMPATIBILITY ⭐

CREATE SEQUENCE conforms to the SQL standard, with the following exceptions:

• obtaining the next value is done using the nextval() function instead of the standard's NEXT VALUE FOR expression.
• the OWNED BY clause is a PostgreSQL extension.

---

🎀 SEE ALSO 🎀

ALTER SEQUENCE (ALTER_SEQUENCE(7)), DROP SEQUENCE (DROP_SEQUENCE(7))

---

okay that's the whole page, you're basically a sequence girlie now 👑💖 huge shoutout to the PostgreSQL 17.11 docs, dated 2026 — this has been CREATE SEQUENCE(7), signing off, slay ✨🦋🎀