SQL Data Types

Every column in a table is declared with a data type. The type tells the database engine exactly what kind of value the column can hold — a whole number, a chunk of text, a date, a yes/no flag — and that decision ripples through everything you do with the table afterward: how much disk space it uses, how fast it can be searched, which operators and functions work on it, and whether invalid data gets rejected at insert time or silently corrupts your reports later.

Data types are not a formality you fill in and forget. Picking the wrong one is one of the most common — and most expensive to fix — mistakes in schema design, because changing a column's type on a table that already has millions of rows and live traffic is a much bigger operation than picking the right type on day one.

The major type categories

Category	Examples	Used for
Numeric	INTEGER, BIGINT, DECIMAL, FLOAT	Counts, quantities, money, measurements
Character / text	CHAR, VARCHAR, TEXT	Names, emails, descriptions, free-form text
Date / time	DATE, TIME, TIMESTAMP, INTERVAL	Timestamps, schedules, durations
Boolean	BOOLEAN	True/false flags — is_active, is_deleted
Binary	BYTEA, BLOB, VARBINARY	Raw bytes — images, files, hashes
Other	JSON/JSONB, UUID, ARRAY, ENUM	Semi-structured or dialect-specific data

A quick look at each in practice

One table, several categories of type

SQL

CREATE TABLE products (
    id          SERIAL PRIMARY KEY,        -- numeric (auto-incrementing)
    name        VARCHAR(120) NOT NULL,     -- character
    description TEXT,                      -- character (unbounded)
    price       DECIMAL(10, 2) NOT NULL,   -- numeric (exact, for money)
    in_stock    BOOLEAN DEFAULT TRUE,      -- boolean
    created_at  TIMESTAMP DEFAULT NOW()    -- date/time
);

Why the right type matters

Storage efficiency — a SMALLINT uses 2 bytes; a BIGINT uses 8 bytes for the same value. Multiplied across billions of rows, that difference is real disk and memory.
Correctness — a DATE column rejects the string "not a date" at insert time; a generic text column would happily store it and break every query that assumes a real date.
Performance — comparisons, sorts, and joins on a compact numeric type are faster than on a long text representation of the same value.
Index effectiveness — indexes are smaller and comparisons cheaper when the underlying type is compact and fixed-size, which means faster lookups.
Available operations — only date types support date arithmetic (adding days, extracting a month); only numeric types support SUM and AVG in a meaningful way.

Type names vary by dialect

The type names above are a common, portable core, but exact names and available options differ meaningfully between PostgreSQL, MySQL, and SQL Server — for example auto-incrementing columns are `SERIAL` in PostgreSQL but `AUTO_INCREMENT` in MySQL and `IDENTITY` in SQL Server. The dedicated pages on Numeric Types, Character & Text Types, Date & Time Types, and Boolean & Binary Types call out these differences in detail.

Tip

When in doubt, pick the narrowest type that comfortably fits your data's realistic range and never store money or exact quantities in a floating-point type — see the Numeric Types page for why.