Skip to content

Supabase database errorSupabase: “value too long for type character varying(n)” (22001)

“value too long for type character varying” is Postgres error 22001. A string is longer than the limit set on a varchar(n) column, so the whole insert or update fails. The usual fix is to change the column to text, which has no limit, and check length in the app if you need one.

Short answer

The number in the error is the limit, such as 255. Find which column has it, then change that column to text, or raise the limit if the number matters. If you need a cap, check the length in the form and with a check constraint, so the user sees a clear message instead of a database error.

Rather not fix it yourself? App Fix Ticket starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.

Why the value is too long, and the fix

  1. 01

    The column has a small limit

    “An attempt to store a longer string into a column of these types will result in an error” PostgreSQL docs, Character types

    Schemas copied from MySQL habits or generated by tools often use varchar(255) for everything. Long names, URLs, notes and tokens don’t fit.

  2. 02

    Find the column

    The error gives the limit but not always the column. List the columns with that limit on the table.

    select column_name, character_maximum_length
    from information_schema.columns
    where table_schema = 'public' and table_name = 'profiles'
      and character_maximum_length is not null;
  3. 03

    Change it to text

    “There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles” PostgreSQL docs, Character types

    text has no limit and, in Postgres, runs no slower than varchar. Change the column in a migration, or raise the limit with type varchar(500) if the number matters. If a view or policy uses the column, the alter fails until you drop and recreate it, and a new length check fails if old rows are already longer.

    alter table public.profiles
      alter column bio type text;
    
    -- keep a cap if you need one
    alter table public.profiles
      add constraint profiles_bio_length check (char_length(bio) <= 2000);
  4. 04

    The limit counts characters, not bytes

    “Both of these types can store strings up to n characters (not bytes) in length.” PostgreSQL docs, Character types

    Most emoji and accented letters count as one character, so the limit isn’t a byte count. In JavaScript, str.length counts some emoji as 2, so check [...str].length before you save.

Checked against the vendor’s docs on : PostgreSQL docs: Character types.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

“Very responsive, attentive to fixing bugs, and completed the project as needed! Thank you!”
A buyer in the United States, July 2022. Shopify on Fiverr
All 127 Fiverr reviews

Related: Supabase violates check constraint · Supabase violates not-null constraint · Supabase migration failed on db push · Supabase invalid input syntax for type uuid

Questions

More on this error

Is changing varchar to text safe?

Yes for the data: every value that fits varchar(n) fits text. But Postgres blocks the change if a view, rule or RLS policy uses the column. Drop those in the same migration, alter the column, then create them again.

Why not just cut the string?

Cutting hides data loss. If a limit is real, tell the user in the form. If it isn’t, remove it.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.