top of page

Welcome
to NumpyNinja Blogs

NumpyNinja: Blogs. Demystifying Tech,

One Blog at a Time.
Millions of views. 

SQL Data Types Made Simple: A Clear Guide for Beginners - Part I

Jan 13
7 min read

In the world of databases, accuracy, and structure are essential. Every piece of information stored in a database must follow a clear rule about what kind of value it represents. These rules are defined through SQL data types. For beginners, understanding data types is one of the most important steps toward writing reliable, efficient SQL queries.


This blog provides a simple, formal, and easy‑to‑understand introduction to SQL data types, designed specifically for new learners.


A data type specifies the kind of data a column in a table can store. It ensures that the database handles information consistently and prevents invalid or incompatible values from being inserted.


Choosing the correct data type is essential because it affects:

  • Storage efficiency

  • Query performance

  • Data accuracy

  • Validation and error prevention


In short, data types help maintain the integrity and reliability of your database.


SQL data types generally fall into four main categories:

  • Numeric

  • String (Character) Data Types 

  • Date and Time Data Types 

  • Other Notable Types


Image generated by AI

Numeric Data Types


SMALLINT

A smaller version of INTEGER. Uses less storage and supports a smaller range of integers. It is good for columns where values will always be small (e.g., age, quantity, flags).

column_name SMALLINT

INTEGER

An integer is a whole number that can be positive or negative. Every SQL system has a maximum size for integers.

You can also specify a precision, like INTEGER (10), which limits the value to 10 digits even if the system supports more. If you specify a precision larger than what the system supports, it won’t work — hardware limits cannot be bypassed. If your application moves to another database system in the future, specifying the precision helps maintain consistent behavior across all platforms.

column_name INTEGER

BIGINT

A larger version of INTEGER. It supports VERY large whole numbers. It is useful for IDs, counters, and systems that generate large numeric values.

column_name BIGINT

NUMERIC

Numeric is used when you want a number that can have decimals.

  • Precision = total digits the number can have

  • Scale = digits after the decimal point

NUMERIC (10,2)

  • Total digits allowed: 10

  • Decimal digits: 2

  • Biggest number it can store: 99,999,999.99

Even if your computer can handle bigger numbers, SQL will only allow what you set in precision.

column_name NUMERIC(precision, scale);

DECIMAL vs NUMERIC

Both are almost the same, but there’s one key difference:

  • DECIMAL may use more precision if your computer system supports it. (Meaning: it might store extra digits beyond what you asked for.)

  • NUMERIC always uses exactly the precision you specify — no more, no less — even if the system can handle more.

So, if you want your numbers to behave the same on every system, choose NUMERIC. It gives consistent results everywhere.

 

REAL 

The REAL data type is used to store numbers with decimals using single‑precision floating‑point format. In simple words, it can store decimal values, but not with perfect accuracy. The exact level of precision depends on the computer’s hardware — a 64‑bit system can store more precise values than a 32‑bit system.


Floating‑point numbers are just numbers with a decimal point, like 2.7 or 2735.53894. However, computers don’t store these numbers the way we write them. Instead, they break the number into two parts: a mantissa (the main value) and an exponent (the power of 10). For example, the number 6.626 × 10⁻³⁴ has a mantissa of 6.626 and an exponent of –34.


This format allows computers to represent extremely large or extremely small numbers, even though the values are approximate rather than exact. REAL is useful when exact precision is not required but a wide range of values is needed.

 

DOUBLE PRECISION

Double Precision is used to store decimal numbers with higher accuracy than REAL. It uses double‑precision floating‑point format, which means it can represent numbers more precisely and handle a wider range of very large or very small values. Because it stores more detail, it also uses more storage space than REAL. DOUBLE PRECISION is a good choice when your calculations require better accuracy, and you cannot afford large rounding errors.

CREATE TABLE scientific_data (
    id INT PRIMARY KEY,
    measurement_value DOUBLE PRECISION,
    latitude DOUBLE PRECISION,
    longitude DOUBLE PRECISION
);

FLOAT

The Float data type is another approximate numeric type used to store decimal numbers. Float allows you to specify how precise the number should be, depending on your needs. Like REAL and DOUBLE PRECISION, it does not store values exactly, but it can represent extremely large or extremely tiny numbers. FLOAT is useful when you need flexibility in precision and when exact accuracy is not required.

CREATE TABLE Products (
    ProductID INT PRIMARY KEY,
    ProductName VARCHAR(255),
    Weight FLOAT(24), -- Single precision (4 bytes)
    Price DOUBLE PRECISION -- Double precision (8 bytes)
);

BOOLEAN 

A BOOLEAN column can store TRUE, FALSE, or UNKNOWN. The UNKNOWN value exists because SQL allows NULL, and any comparison with NULL results in UNKNOWN. So:

  • TRUE vs NULL → UNKNOWN

  • FALSE vs NULL → UNKNOWN

  • UNKNOWN vs anything → UNKNOWN

CREATE TABLE assertions (
    claim TEXT,
    really BOOLEAN
);

String (Character) Data Types 

In SQL, after numbers, the next most common type of data is text — things like names, addresses, and codes. SQL gives you different text data types depending on how you want to store that text.

The main types are:

  • CHAR

  • VARCHAR

  • CLOB

 

CHAR (Fixed‑Length Text)

A CHAR column stores text with a fixed length.

Name CHAR(15)

This means the column can store up to 15 characters. If the actual text is shorter, SQL fills the extra space with blank characters.

 

VARCHAR (Variable‑Length Text)

VARCHAR works like CHAR, but without padding.

Name VARCHAR(15)

This also allows up to 15 characters, but:

  • "Ananth" is stored as just 6 characters

  • No extra blanks are added

  • Storage adjusts to the actual length of the text


In Simple Terms:

  • CHAR → fixed size, always uses the full length

  • VARCHAR → flexible size, uses only what it needs

 

CLOB

A CLOB (Character Large Object) is used when you need to store very large amounts of text—more than what CHAR or VARCHAR can hold. For example, if your database only allows up to 1,024 characters in a VARCHAR field, but you need to store thousands of characters, you will use a CLOB.


However, CLOBs are not very flexible. You can store and retrieve the text, but you cannot easily search inside it, find specific characters, or manipulate the text the way you can with CHAR or VARCHAR. You can only do basic operations like checking if two CLOB values are equal.

Dream CLOB (8721)

Date and Time Data Types 

SQL has several data types for storing dates, times, or both. Different database systems support different datetime types, so moving a database from one system to another can sometimes cause compatibility issues. There’s no universal fix — you handle it when it comes up.


DATE

The date data type stores only the year, month, and day. It does not store the time of day. It uses the format yyyy‑mm‑dd.


Example:

1969‑07‑20 (the date of the Apollo 11 Moon landing)


Use DATE when you only care about the day, not the time.

 

TIME WITHOUT TIME ZONE

Time without time zone stores only the time of day 

— hours, minutes, and seconds

— without any date and without any time‑zone information.


Example:

02:56:31 → 2:56 AM and 31 seconds


You can also store fractions of a second by adding a precision value:


Example:

TIME WITHOUT TIME ZONE (2) This stores time down to hundredths of a second, like: 02:56:31.17


Use this type when you only care about the time, not the date or time zone.

 

TIME WITH TIME ZONE

Time with time zone stores the time of day (hours, minutes, seconds) plus the time zone the time belongs to.

All time zones are measured relative to UTC (Coordinated Universal Time), which is the standard time used worldwide. Different places are either ahead of or behind UTC by a certain number of hours.


Example:

A time might be stored as: 02:56:31+05:30 → meaning 2:56 AM in a time zone that is 5 hours and 30 minutes ahead of UTC.


Time zones around the world range from about UTC‑12:59 to UTC+13:00, depending on location and Daylight-Saving Time.


In short: Use Time with time zone when you need the exact time and the time zone it belongs to.

 

TIMESTAMP WITHOUT TIME ZONE

This data type stores both the date and the time, but without any time‑zone information. It’s basically DATE + TIME in one value.


Example:

1969‑07‑21 02:56:31


You can choose how many decimal places to store for seconds (default is 6, but you can set it to 0).

 

TIMESTAMP WITH TIME ZONE

This type stores date + time + time zone. It works like timestamp with time zone but adds an offset showing how far the time is from UTC.


Example:

1969‑07‑20 21:56:31‑05:00


Use this when the time zone matters.


INTERVAL

In SQL, an interval is used to show how much time lies between two dates, times, or timestamps.


SQL separates intervals into two groups:

  • YEAR TO MONTH → for differences in years and months

  • DAY TO SECOND → for differences in days, hours, minutes, seconds


Because months have different lengths, SQL doesn’t allow mixing the two types in one interval


Correct Example:

SELECT INTERVAL '2 years 3 months';
SELECT INTERVAL '10 days 5 hours';

Incorrect Example:

INTERVAL '2 years 7 months 13 days'

Is not allowed because it mixes both interval types


You’ve now got the basics of SQL data types down — the core building blocks every table relies on. In Part ll, We will be covering other notable data types in SQL. . It’s simpler than it sounds, and you’ll see how these help you handle more complex data.


Click here to continue part II reading!


Happy Reading :)


 
 

+1 (302) 200-8320

NumPy_Ninja_Logo (1).png

Numpy Ninja Inc. 8 The Grn Ste A Dover, DE 19901

© Copyright 2025 by Numpy Ninja Inc.

  • Twitter
  • LinkedIn
bottom of page