Snowflake data types 101: Overview of 6 essential types (2026)

Snowflake supports a wide range of data types covering everything from integers and decimals to JSON blobs and GPS coordinates. Selecting the right Snowflake data type isn’t just good hygiene; it can directly affects storage efficiency, query speed and data integrity. Pick it wrong and you’ll spend time debugging precision errors, bloated storage bills or even broken ETL pipelines.

In this article, we cover the 6 core categories of Snowflake data types with practical examples for each. We’ll also flag which types are not supported, and touch on some newer additions like DECFLOAT, VECTOR and structured types worth knowing about in 2026.

What are Snowflake data types?

Snowflake supports most standard SQL data types, and then some. Beyond the usual numbers, text and dates, it extends into semi-structured formats like JSON and Parquet, plus geospatial types for location-aware analytics. You can use these types in table columns, local variables, expressions, function parameters and other suitable locations.

Carefully selecting appropriate data types is crucial in Snowflake to balance flexibility, storage efficiency and streamline query performance.

Now, let’s look at the 6 different categories of data types offered natively by Snowflake.

Categories of Snowflake data types

Snowflake organizes data types into 6 primary categories:

• Numeric data types
• String & binary data types
• Logical data types
• Date & time data types
• Semi-structured data types
• Geospatial data types

Fresh new updates in 2026: Snowflake has expanded its type system beyond these 6. You’ll now also find structured data types (typed ARRAY, OBJECT and MAP), a VECTOR type for machine learning workloads, a UUID type and a FILE type (in preview) for unstructured data like images and PDFs. This article focuses on the 6 core categories, but we flag the newer additions where relevant.

Check out this video for a quick rundown of the data types available in Snowflake.

1) Numeric data types

Numeric Snowflake data types allow storing numeric values including whole numbers, decimals, floating point numbers, doubles, etc. Choosing the right numeric type is important for accuracy and efficient storage and processing.

Here are some of the common numeric data types in Snowflake:

NUMBER

NUMBER is the foundational fixed-point numeric type in Snowflake. It takes two parameters: precision and scale.

Precision is the total number of digits allowed. Scale is how many of those digits sit to the right of the decimal point.

So NUMBER(5, 2) allows values like 123.45 or -99.99. The five total digits, two of which are fractional, cap your range at anything from -999.99 to 999.99.

Note:

• Precision doesn’t affect storage size. A NUMBER(5, 0) column and a NUMBER(38, 0) column consume identical storage for the same values. Snowflake determines storage per micro-partition based on the actual value range — so a column that only ever holds values between -128 and 127 costs 1 byte per value, regardless of declared precision
• Scale does affect storage. More fractional digits means more bytes and slightly slower processing
• The maximum scale is 37. A value like 1.2e-39 can’t be represented without precision loss
• Default: NUMBER(38, 0)

Remember that, if you convert a high-precision NUMBER to a lower-precision type (like FLOAT) and back, you’ll lose digits permanently.

Here’s a simple example illustrating the use of the NUMBER Snowflake data type

-- Creating a table with NUMBER snowflake data type - data type in Snowflake
CREATE TABLE number_table (
	num1 NUMBER(5,2), 
	num2 NUMBER 
);

INSERT INTO number_table VALUES
	 (-999, 999999);

DESC TABLE number_table;	

DECIMAL, DEC, NUMERIC

DECIMAL enables fixed point decimal arithmetic by explicitly defining value range via precision and scale. DECIMAL, DEC and NUMERIC are also synonymous with NUMBER. The default value for precision and scale of DECIMAL is also same as number (i.e. DECIMAL(38, 0))

Here’s a simple example illustrating the use of the DECIMAL Snowflake data type:

-- Creating a table with DECIMAL snowflake data type - data type in Snowflake
CREATE TABLE decimal_table (
	num1 DECIMAL(5,2), 
	 num2 DECIMAL 
);

INSERT INTO decimal_table VALUES
	(-999, 999999);

DESC TABLE decimal_table; 

INT, INTEGER, BIGINT, SMALLINT, TINYINT, BYTEINT

Integer is also synonymous with NUMBER, except that precision and scale cannot be specified. Whenever you are modeling whole numbers in Snowflake, you have a number of integer types to choose from INT, BIGINT, SMALLINT and more. These different types actually behave very similarly, simply allowing different ranges of integers to be stored.

In Snowflake, every integer type (SMALLINT included) can hold values from -99,999,999,999,999,999,999,999,999,999,999,999,999 to +99,999,999,999,999,999,999,999,999,999,999,999,999. That’s a 38-digit range, far beyond the 32,767 cap you’d find for SMALLINT in standard SQL.

The different type names exist purely for compatibility with other systems and as hints to developers about expected value ranges. SMALLINT doesn’t constrain values to a small range the way it would in PostgreSQL or MySQL. It’s a convention, not a constraint.

Storage-wise, Snowflake compresses values and determines per-partition storage based on the actual min/max values within that micro-partition. So a column of small integers stored as BIGINT won’t waste space.

Here’s a simple example illustrating the use of the integer Snowflake data type:

CREATE OR REPLACE TABLE integer_table (
		 small_number SMALLINT,
		 regular_int INT,
		 big_number BIGINT
);

-- Inserting values
INSERT INTO integer_table (small_number, regular_int, big_number) VALUES 
(-32768, 2147483647, 9223372036854775807);

-- Query to describe the table
DESC TABLE integer_table;

In short, these integer types offer different intuitive “buckets” for whole number modeling without fractions.

FLOAT , FLOAT4 , FLOAT8

Despite their names suggesting different sizes, FLOAT, FLOAT4 and FLOAT8 are all treated identically in Snowflake: 64-bit double-precision floating-point numbers following the IEEE 754 standard. There is no 32-bit FLOAT in Snowflake.

Key specs:

• Precision: approximately 15 significant decimal digits
• Integer range: -9,007,199,254,740,991 to +9,007,199,254,740,991
• Floating-point range: approximately 10^-308 to 10^+308

Snowflake also supports special values for FLOAT:

• NaN (Not A Number).
• in (infinity).
• -inf (negative infinity).

These are case-insensitive and must be quoted.

One important deviation from IEEE 754: Snowflake treats all ‘NaN’ values as equal, and considers ‘NaN’ greater than any other FLOAT value (including infinity). Standard IEEE 754 says NaN comparisons return false.

Floating-point rounding errors are real. They can vary per query execution and accumulate in aggregate functions like SUM() or AVG(). If you need exact results, cast to a fixed-point type before aggregating or use DECFLOAT (see below).

Here’s a detailed example of using FLOAT Snowflake data types:

-- Creating a table with FLOAT snowflake data type - data type in Snowflake
CREATE OR REPLACE TABLE float_table (
		regular_float FLOAT,
		small_float FLOAT4,
		 large_float FLOAT8
);

INSERT INTO float_table (regular_float, small_float, large_float) VALUES 
(123.456, 789.1011, 112233.445566);

-- Query to describe the table 
DESC TABLE float_table;

DOUBLE , DOUBLE PRECISION , REAL

DOUBLE, DOUBLE PRECISION and REAL are also synonymous with FLOAT, meaning they are also treated as 64-bit floating-point numbers. These types are also designed to handle numbers that require large ranges and significant precision, especially useful in scenarios where FLOAT is used to represent real-world data with a high degree of accuracy.

Here’s a detailed example of using DOUBLE Snowflake data type:

-- Creating a table with DOUBLE snowflake data type - data type in Snowflake
CREATE OR REPLACE TABLE double_table (
		column_double DOUBLE,
		 column_double_precision DOUBLE PRECISION,
		column_real REAL
);

INSERT INTO double_table (column_double, column_double_precision, column_real) VALUES 
(123456.789, 987654.321, 12345.6789);

-- Query to describe the table
DESC TABLE double_table;

DECFLOAT

DECFLOAT is worth calling out separately because it solves a specific problem: exact decimal arithmetic with a wide, variable exponent range.

Unlike NUMBER (fixed scale) and FLOAT (approximate), DECFLOAT stores exact values with up to 38 significant digits and a dynamic base-10 exponent ranging from -16,383 to +16,384. That covers values roughly from 10^-16383 to 10^+16384.

DECFLOAT is ideal when:

• You’re ingesting data with unknown or highly variable scale
• You need exact results for financial modeling, ledgers or compliance
• You’re migrating from Oracle DECIMAL or DB2 DECFLOAT columns
• You’re hitting Number out of representable range errors on high-precision aggregations

Note that DECFLOAT doesn’t support NaN, inf or -inf; those are FLOAT-only.

Numeric constants

Numeric constants, also known as literals, are fixed data values. They follow specific formats:

[+-][digits][.digits][e[+-]digits]

• The format can include an optional sign (+ or -), where the default is positive if not specified.
• It consists of digits (0 to 9), which can be placed before or after a decimal point.
• The letter e or E is used to denote scientific notation, indicating an exponent. If an exponent is present, it must be followed by at least one digit.

2) String & Binary—Snowflake data types

String and Binary Snowflake data types are integral for managing text and binary data. These Snowflake data types uniformly handle Unicode UTF-8 characters, ensuring consistent data handling across various string types.

Here are some of the common String & Binary data types in Snowflake:

VARCHAR

VARCHAR is the most versatile string data type in Snowflake, accommodating Unicode UTF-8 characters. Its length can be defined up to 16,777,216 characters or 16 MB, but if unspecified, it defaults to this maximum.

Regarding performance, there is no performance difference between using the full-length VARCHAR declaration VARCHAR(16777216) and a smaller length.

This Snowflake data type is really good for storing text where the length might vary, such as names, descriptions or comments…

For Example:

-- Creating a table with VARCHAR snowflake data type - data type in Snowflake
CREATE TABLE user_reviews (
		 review_id INT,
		 review_text VARCHAR(500)
);

INSERT INTO user_reviews VALUES (1, Some awesome reviews......');

DESC TABLE user_reviews;

CHAR, CHARACTER, NCHAR

Synonymous with VARCHAR, with one difference: if you don’t specify a length, it defaults to CHAR(1) instead of 16,777,216.

Also worth knowing: unlike standard SQL, Snowflake does not space-pad CHAR values to their declared length. A 3-character string in a CHAR(10) column stays 3 characters.

For Example:

-- Creating a table with CHAR snowflake data type - data type in Snowflake
CREATE TABLE user_initials (
		employee_id INT,
		initials CHAR(3)
);

INSERT INTO user_initials VALUES (123, 'Mr.');

DESC TABLE user_initials;

STRING, TEXT, NVARCHAR, NVARCHAR2, CHAR VARYING, NCHAR VARYING

STRING, TEXT, NVARCHAR, NVARCHAR2, CHAR VARYING, NCHAR VARYING are all synonymous with VARCHAR. You’ll see these in codebases migrated from Oracle, MySQL or other systems. In Snowflake, they behave identically to VARCHAR.

For example:

-- Creating a table with STRING snowflake data type - data type in Snowflake
CREATE TABLE product_descriptions (
		 product_id INT,
		description TEXT
);

INSERT INTO product_descriptions VALUES (456, 'Somke awesome description....');

DESC TABLE product_descriptions;

STRING vs VARCHAR: In some databases, STRING implies fixed-length storage. In Snowflake, they’re the same type.

BINARY

BINARY stores fixed-length binary data measured in bytes — not characters. It’s suited for raw binary payloads like cryptographic hashes, encoded file content or binary protocol data.

Maximum size: 67,108,864 bytes (~64 MB).

Note: there’s no Unicode concept here. The length is always measured in bytes.

For example:

-- Creating a table with BINARY snowflake data type - data type in Snowflake
CREATE TABLE user_avatars (
		 user_id INT,
		 avatar BINARY(1000)
);

DESC TABLE user_avatars;

VARBINARY

VARBINARY is the variable-length counterpart to BINARY. Same ~64 MB ceiling, but it adjusts to the actual byte length of each stored value. Use it over BINARY when your binary payloads have variable sizes.

For Example:

-- Creating a table with VARBINARY snowflake data type - data type in Snowflake
CREATE TABLE file_storage (
		 file_data VARBINARY
);

DESC TABLE file_storage;

String constants

String constants (literals) are used for representing fixed text values. Snowflake supports single-quoted and dollar-quoted string constants. The former requires escaping special characters like single quotes, while the latter is useful for complex strings containing special characters or spanning multiple lines.

Single-Quoted String Constants: Enclosed between single quotes (‘), using two single quotes to represent a quote within the string.

SELECT 'Snowflake''s power is insane';

Dollar-Quoted String Constants: Enclosed between pairs of dollar signs ($$), useful for strings that include quotes or special characters.

SELECT $$String with 'quotes' and multiple
lines without needing escape sequences.$$;

Check this Snowflake documentation to learn more in-depth on String & Binary Snowflake data type.

3) Logical—Snowflake data types

Snowflake’s logical data type is BOOLEAN, which represents true or false values. It can also have an “unknown” value, represented by NULL. You can use BOOLEAN in various parts of your query, like in a SELECT list or a WHERE clause, to make decisions based on logical conditions.

Conversions to BOOLEAN

Explicit conversion via TO_BOOLEAN():

• Strings: ‘true’, ‘yes’, ‘on’, ‘1’ convert to TRUE; ‘false’, ‘no’, ‘off’, ‘0’ convert to FALSE; case-insensitive
• Numbers: 0 converts to FALSE; any non-zero converts to TRUE

Implicit conversion follows the same rules when Snowflake can infer intent from context.

Conversions from BOOLEAN

• TRUE converts to ‘true’ (string) or 1 (numeric)

FALSE converts to ‘false’ (string) or 0 (numeric)

For Example:

Creating and Inserting data:

CREATE TABLE test_boolean(b BOOLEAN, n NUMBER, s STRING);
INSERT INTO test_boolean VALUES (true, 1, 'yes'), (false, 0, 'no'), (null, null, null);

Using BOOLEAN in expressions:

-- Using BOOLEAN snowflake data type in Expressions - data type in Snowflake
SELECT b, n, NOT b AND (n < 1) FROM test_boolean;

Using BOOLEAN in predicates:

SELECT * FROM test_boolean WHERE NOT b AND (n < 1);

Text to BOOLEAN conversion:

SELECT s, TO_BOOLEAN(s) FROM test_boolean;

Number to BOOLEAN conversion:

SELECT n, TO_BOOLEAN(n) FROM test_boolean;

Implicit conversion to Text:

SELECT 'Text for ' || s || ' is ' || b AS result FROM test_boolean;

4) Date & Time—Snowflake data types

Snowflake’s date and time types cover calendars, clock times and timestamps, with fine control over time zone handling and sub-second precision.

Let’s dive deeper into each Date & Time data type in Snowflake

DATE

DATE stores calendar dates only. No time component. It accepts multiple formats (YYYY-MM-DD, DD-MON-YYYY) and discards any time information when converting from a TIMESTAMP.

Snowflake recommends using dates between 1582 and 9999. Dates outside that range can behave unexpectedly due to historical calendar reforms.

For example:

-- Creating a table with DATE snowflake data type - data type in Snowflake
CREATE TABLE project_deadlines (project_name STRING, deadline DATE);
INSERT INTO project_deadlines VALUES ('Some	Project', '2023-07-20');
DESC TABLE project_deadlines;

DATETIME

DATETIME is an alias for TIMESTAMP_NTZ. It stores a date and time without any time zone context. Use it when the time zone is irrelevant or managed externally by your application.

For example:

CREATE TABLE meeting_schedule (meeting_topic STRING, meeting_datetime DATETIME);
INSERT INTO meeting_schedule VALUES ('Budget Review', '2023-07-21 10:00:00');

TIME

TIME stores a time-of-day value without a date. Fractional seconds precision ranges from 0 (whole seconds) to 9 (nanoseconds). Useful for recurring schedules, business hours or time-of-day analytics.

For example:

-- Creating a table with TIME snowflake data type - data type in Snowflake
CREATE TABLE store_hours (day_of_week STRING, opening_time TIME, closing_time TIME);
INSERT INTO store_hours VALUES ('Monday', '08:00:00', '18:00:00');
DESC TABLE store_hours;

TIMESTAMP Variants

Snowflake has three distinct TIMESTAMP types, and picking the wrong one causes silent data errors in multi-region or multi-timezone pipelines.

TIMESTAMP_LTZ (local time zone): Stores the time internally as UTC, then converts to the session’s local time zone for display. Best for recording the exact moment something happened globally.

TIMESTAMP_NTZ (no time zone): Stores the time as-is, with no time zone info. DATETIME is an alias for this. Use it when time zone context is externally managed or simply irrelevant.

TIMESTAMP_TZ (with time zone): Stores both the time and an explicit time zone offset. The offset is preserved as part of the data. Use it for scheduling across regions or whenever the origin time zone matters.

TIMESTAMP (without a suffix) is an alias for one of these variants; TIMESTAMP_NTZ by default, but configurable via the TIMESTAMP_TYPE_MAPPING session parameter.

For example:

-- Creating a table with TIMESTAMP snowflake data type - data type in Snowflake
CREATE TABLE meetings (meeting_name STRING, start_time TIMESTAMP_TZ);
INSERT INTO meetings VALUES ('Global Sync', '2023-07-22 15:00:00 +0100');

Check this Snowflake documentation to learn more in-depth on DATE & TIME Snowflake data type.

These Snowflake data types offer great flexibility and precision in handling date and time data.

5) Semi-structured—Snowflake data types

Semi-structured types are what make Snowflake genuinely useful for modern data pipelines. You can load JSON, Avro, ORC, Parquet or XML directly without defining a rigid schema upfront.

VARIANT

VARIANT is the most flexible type in Snowflake. It holds any value: a string, a number, a boolean, an array, an object or even NULL. It stores both the value and its type, so you can operate on the data without explicit casting in most cases.

Maximum size per VARIANT value: 16 MB (uncompressed).

VARIANT is particularly useful for staging raw JSON before transforming it into structured columns, or for storing heterogeneous data where the schema isn’t consistent across rows.

For example:

-- Creating a table with VARIANT snowflake data type - data type in Snowflake
CREATE TABLE user_data (user_info VARIANT);
INSERT INTO user_data SELECT PARSE_JSON('{"name": "Genius", "age": 40}');
DESC TABLE user_data;

OBJECT

OBJECT is analogous to a JSON object or dictionary. It stores key-value pairs where each key is a VARCHAR and each value is a VARIANT.

-- Creating a table with OBJECT snowflake data type - data type in Snowflake
CREATE TABLE user_profiles (id INT, details OBJECT);
INSERT INTO user_profiles(details) SELECT OBJECT_CONSTRUCT('name', 'Chaos', 'age', 35, 'location', 'SF');
DESC TABLE user_profiles;

ARRAY

ARRAY holds an ordered list of VARIANT elements. Elements can be of different types, though in practice they’re usually uniform. You access elements by position (zero-indexed).

Snowflake doesn’t support fixed-size arrays or arrays typed to a specific non-VARIANT type in the semi-structured context. For typed arrays, see the structured data types (ARRAY with type parameters) introduced more recently.

-- Creating a table with ARRAY snowflake data type - data type in Snowflake
CREATE TABLE snowflake_size (_id INT, sizes ARRAY);
INSERT INTO snowflake_size(sizes) SELECT ARRAY_CONSTRUCT('XS','S', 'M', 'L', 'XL');
DESC TABLE snowflake_size;

Check this Snowflake documentation to learn more in-depth on Semi-structured Snowflake data type.

Structured variants (typed ARRAY, OBJECT, MAP): Snowflake now supports structured versions of these types. For example, ARRAY(VARCHAR) or MAP(VARCHAR, NUMBER). These enforce type constraints at the column level and can reduce storage overhead versus untyped semi-structured columns. They’re worth exploring if you’re building production pipelines with well-known schemas.

6) Geospatial—Snowflake data types

Geospatial Snowflake data types refers to information about geographic locations and shapes like points, lines and polygons on the earth’s surface. Snowflake provides two data types to store and analyze this type of location data, they are:

GEOGRAPHY

GEOGRAPHY uses spherical coordinates following the WGS 84 standard. It is the same coordinate system GPS uses. Lines between points are treated as geodesic (curved) paths along Earth’s surface, which is what you want for real-world distance and area calculations.

Use GEOGRAPHY when accuracy on a global scale matters: shipping routes, coverage areas, proximity searches across continents.

-- Creating a table with GEOGRAPHY snowflake data type
CREATE TABLE cities (
	 location GEOGRAPHY 
);

INSERT INTO cities
	VALUES ('POINT(-122.4783 37.8199)');

GEOMETRY

GEOMETRY uses a flat (planar) Cartesian coordinate system. Lines between points are straight, which works well for localized or projected coordinate systems like engineering surveys, architectural floor plans or data from projected CRS (coordinate reference systems).

-- Creating a table with GEOMETRY snowflake data type - data type in Snowflake
CREATE TABLE survey_zones (
	 outline GEOMETRY
);

INSERT INTO survey_zones 
	VALUES ('POLYGON((0 0, 0 1, 1 1, 1 0, 0 0))');

DESC TABLE survey_zones;

What are the supported Geospatial Object Types?

Both GEOGRAPHY and GEOMETRY support the following formats and object types:

WKT, WKB, EWKT, EWKB and GeoJSON:

• Point
• MultiPoint
• LineString
• MultiLineString
• Polygon
• MultiPolygon
• GeometryCollection

GeoJSON-specific:

• Feature
• FeatureCollection

TL;DR: use GEOGRAPHY for real-world lat/lon data on a globe; use GEOMETRY for flat-plane coordinate systems. Both integrate with Snowflake’s spatial SQL functions for location-based queries.

Which datatype is not supported by Snowflake?

A few types common in other database systems don’t exist in Snowflake:

LOB (large object) types

• BLOB: Not supported. Use BINARY instead, up to 67,108,864 bytes (~64 MB)
• CLOB: Not supported. Use VARCHAR instead, up to 134,217,728 bytes (128 MB) for single-byte characters

Other unsupported types

• ENUM: Not supported. Use VARCHAR with application-level validation or a lookup table as an alternative

Conclusion

And that’s a wrap! Snowflake data types span the full spectrum from basic integers to geospatial coordinates and raw binary payloads. The 6 core categories (numeric, string & binary, logical, date & time, semi-structured and geospatial) cover most real-world data modeling needs. Newer additions like DECFLOAT, VECTOR and structured types (typed ARRAY, OBJECT, MAP) are worth tracking as Snowflake’s type system continues to grow.

In this article, we covered:

• What Snowflake data types are and why they matter
• Numeric data types (NUMBER, DECIMAL, INT variants, FLOAT, DOUBLE, DECFLOAT)
• String & binary data types (VARCHAR, CHAR, BINARY, VARBINARY and their aliases)
• Logical data types (BOOLEAN)
• Date & time data types (DATE, TIME, DATETIME and TIMESTAMP variants)
• Semi-structured data types (VARIANT, OBJECT, ARRAY)
• Geospatial data types (GEOGRAPHY, GEOMETRY)
• Which data types Snowflake doesn’t support

…and so much more!

FAQs