Incident brief
Value too long for character varying(n)
A string was too long to fit in a length-limited column. PostgreSQL rejects it, except in one narrow case the manual calls out by name.
What lands in your log
ERROR: value too long for type character varying(5)
In 10 seconds
- What triggers it
- Create a table with a varchar(5) column.
- Fix
- Widen the column if longer values are genuinely valid data.
- Proof
- Reproduced on PostgreSQL 16.14 → Inserting 'toolongname' (11 characters) into a varchar(5) column was rejected with SQLSTATE 22001. No row was stored.
Fix
What to do right now
Application-level steps for this error.
- Widen the column if longer values are genuinely valid data.
- Validate or trim the string length in the application before inserting.
- Use text instead of a length-limited type when there's no real limit to enforce.
-- widen the column so a legitimately longer value fits
ALTER TABLE growth.beta_signups ALTER COLUMN username TYPE varchar(20);
INSERT INTO growth.beta_signups (id, username) VALUES (4, 'toolongname');For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Value too long for character varying(n) is a mismatch between the bound value and the target type. Inspect the target definition, then log the rejected value at the application boundary.
Character limits on stored columns
Find the target columns whose declared limits can produce this SQLSTATE.
SELECT table_schema, table_name, column_name, data_type,
character_maximum_length
FROM information_schema.columns
WHERE character_maximum_length IS NOT NULL
ORDER BY character_maximum_length, table_schema, table_name
LIMIT 100;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, §8.3 Character Types
An attempt to store a longer string into a column of these types will result in an error, unless the excess characters are all spaces, in which case the string will be truncated to the maximum length.Read the full section on postgresql.org →
The insert that's too long
PostgreSQL measured the string at 11 characters against the column's 5-character limit and rejected the insert outright.Checking the table afterward
The table is empty. The rejected insert left no truncated or partial row behind.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Create a table with a varchar(5) column.
- 2Insert a plain string longer than 5 characters.
- 3PostgreSQL rejects it with SQLSTATE 22001 instead of storing a cut-off value.
One client: create a varchar(5) column, insert a plain string that's too long for it.
CREATE SCHEMA IF NOT EXISTS growth;
DROP TABLE IF EXISTS growth.beta_signups;
CREATE TABLE growth.beta_signups (
id integer primary key,
username varchar(5)
);INSERT INTO growth.beta_signups (id, username) VALUES (1, 'toolongname');SELECT * FROM growth.beta_signups;What PostgreSQL actually returned
DROP TABLE
CREATE TABLEERROR: value too long for type character varying(5) id | username
----+----------
(0 rows)The manual's own exception was tested directly: an explicit cast to varchar(5) truncates an over-length value instead of raising an error, a different behavior from the plain insert above.
Without this
Above: a plain insert with no cast raises SQLSTATE 22001.
With this, tested
Below: the same value, explicitly cast to varchar(5), is silently truncated to 5 characters instead.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that looks safe but isn't the only silent-truncation case: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Runbook to fix this
The runbook for this incident
Full step-by-step fixes for the condition behind this error: the diagnosis, the exact SQL, and output captured in the lab.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Understand the concept
Fix it — runbooks
Related errors
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.