Text length & DB size

Reading characters and bytes

文A😀 contains 3 code points, 8 UTF-8 bytes and 4 UTF-16 units. Combining characters or family emoji may look like one character but contain several code points. Input is not normalized or trimmed.

Maximum 100,000 UTF-16 units. Characters are Unicode code points. The count without whitespace removes spaces, tabs and line breaks.

Understanding DB limits

String checks Unicode code point length for general text; it is not an SQL type.

Assumes utf8mb4. CHAR/VARCHAR n counts characters. Other column, index and row limits apply separately.

Assumes utf8mb4. CHAR/VARCHAR count characters; integer types check value ranges. UNSIGNED is available.

Assumes UTF-8. CHAR/VARCHAR n counts characters; NUL cannot be stored.

SQL columns with AL32UTF8. Select BYTE or CHAR explicitly. Checks the byte ceiling too: VARCHAR2 4,000 STANDARD or 32,767 EXTENDED; CHAR 2,000, including space padding with character semantics. NUMBER(p,0)/INTEGER check exact integer ranges without rounding, not storage bytes. Empty strings become NULL.

SQL Server 2019+. VARCHAR/CHAR assume a UTF-8 collation and n counts bytes. NVARCHAR/NCHAR count UTF-16 units under a supplementary-character-aware collation. Legacy code pages such as CP949 and MAX types are outside this model.

Bytes show the UTF-8 input payload. CHAR padding, length headers, indexes and row overhead are excluded. Only length and integer range are checked; database insertion is not guaranteed.

Same input, different DB length rules

These examples compare input payload and column length. No database is contacted and total row storage is not estimated.

SQL to check length in your DB

The examples compare A😀: A followed by one emoji. It contains 2 code points, 3 UTF-16 units and 5 UTF-8 bytes. Column capacity can use a different unit for the same text.

These SELECT examples only read constant strings. This site does not connect to your database or execute queries. Values are expected under the stated conditions, not measurements from a live DB.

MySQL · MariaDB · PostgreSQL

MySQL and MariaDB assume utf8mb4; PostgreSQL assumes server encoding UTF8. Compare character and byte counts. MariaDB LENGTH can change meaning by mode, so OCTET_LENGTH is used for bytes.

SELECT CHAR_LENGTH(s) AS characters,
       OCTET_LENGTH(s) AS bytes
FROM (SELECT CONVERT(0x41F09F9880 USING utf8mb4) AS s) AS sample;

SELECT char_length(s) AS characters,
       octet_length(s) AS bytes
FROM (SELECT convert_from(decode('41f09f9880', 'hex'), 'UTF8') AS s) AS sample;

SQL Server · NVARCHAR

The SQL Server example specifies NVARCHAR and an SC collation. LEN omits trailing spaces; DATALENGTH includes them. Dividing NVARCHAR bytes by 2 gives UTF-16 units. Do not compare this directly with UTF-8 VARCHAR bytes.

SELECT LEN(N'A😀' COLLATE Latin1_General_100_CI_AS_SC) AS characters,
       DATALENGTH(N'A😀') AS bytes,
       DATALENGTH(N'A😀') / 2 AS utf16_units,
       LEN(N'A😀 ' COLLATE Latin1_General_100_CI_AS_SC) AS trailing_space_len,
       DATALENGTH(N'A😀 ') AS trailing_space_bytes;

Oracle · AL32UTF8

The Oracle example assumes database character set AL32UTF8 and VARCHAR2. It converts a UNISTR value into the database character set, avoiding literal emoji in the SQL file. Other character sets may lose characters or produce different results.

SELECT LENGTH(s) AS characters,
       LENGTHB(s) AS bytes
FROM (SELECT CAST(UNISTR('A\D83D\DE00') AS VARCHAR2(20 CHAR)) AS s FROM dual);

If the web result differs, compare the database character set, column type, collation, trailing spaces, CHAR padding and input normalization. A matching length does not rule out NOT NULL, UNIQUE, CHECK or row-size failures.

Related tools