> ## Documentation Index > Fetch the complete documentation index at: https://docs.prequel.co/llms.txt > Use this file to discover all available pages before exploring further. # Data types > Understanding how Prequel Import normalizes source data types ## Understanding Prequel data types Because data can be imported from many different source systems, and because data types are not necessarily synonymous across data stores, Prequel Import normalizes every source column into a common Prequel type. The Prequel type determines how each value is represented once it lands in your datalake and how it is delivered to your destination. ## Source type mapping Reference this table to see how each source column type is normalized into a Prequel type. | Prequel Type | BigQuery | Postgres | Redshift | Snowflake | Object storage & SFTP | | ------------ | ---------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------- | | `bytes` | `bytes` | `bytea` | `binary varying`, `varbinary`, `varbyte` | `binary`, `varbinary` | `blob` | | `string` | `string` | `char`, `character`, `character varying`, `text`, `uuid`, `varchar` | `bpchar`, `char`, `character`, `character varying`, `nchar`, `nvarchar`, `text`, `varchar` | `char`, `character`, `string`, `text`, `varchar` | `char`, `text`, `uuid`, `varchar` | | `boolean` | `bool`, `boolean` | `bool`, `boolean` | `bool`, `boolean` | `boolean` | `bool`, `boolean` | | `integer` | `int`, `int64`, `smallint` | `int`, `int2`, `int4`, `integer`, `short`, `smallint` | `int`, `int2`, `int4`, `integer`, `smallint`, `tinyint` | `int`, `integer`, `number`, `smallint` | `integer`, `smallint` | | `bigint` | `bigint`, `integer` | `bigint`, `int8` | `bigint`, `int8` | `bigint` | `bigint` | | `decimal` | `bignumeric`, `decimal`, `numeric` | `decimal`, `numeric` | `dec`, `decimal`, `numeric` | `decimal`, `fixed`, `numeric` | `decimal`, `numeric` | | `float` | `float`, `float64` | `double`, `double precision`, `float`, `float4`, `float8`, `real` | `double`, `double precision`, `float`, `float4`, `float8`, `real` | `double`, `double precision`, `float`, `float4`, `float8`, `real` | `double`, `real` | | `timestamp` | `timestamp` | `timestamptz`, `timestamp with time zone` | `timestamptz`, `timestamp with time zone` | `timestamptz`, `timestamp_ltz`, `timestamp_tz` | `timestamptz` | | `date` | `date` | `date` | `date` | `date` | `date` | | `json` | `json` | `json`, `jsonb` | `super` | `object`, `variant` | `json` | | `time` | `time` | `time`, `time without time zone` | `time`, `timetz`, `time with time zone`, `time without time zone` | `time` | `time` | | `geography` | `geography` | `geometry`, `point`, `linestring`, `polygon`, `multipoint`, `multilinestring`, `multipolygon` | `geography`, `geometry`, `point`, `linestring`, `polygon`, `multipoint`, `multilinestring`, `multipolygon` | `geography`, `geometry` | `geometry` | | `vector` | `array` | `array`, `double[]`, `_float4`, `_float8` | `array` | `array` | `double[]` | **Timestamps without a time zone are handled as RFC 3339 strings** Source timestamp types that do not carry a time zone are mapped to the Prequel `string` type rather than `timestamp`. Assuming a time zone such as UTC would be incorrect and could mislead downstream consumers. This applies to: * BigQuery `datetime` * Postgres `timestamp` and `timestamp without time zone` * Redshift `timestamp` and `timestamp without time zone` * Snowflake `datetime`, `timestamp`, and `timestamp_ntz` * Object storage and SFTP `timestamp` These values are preserved as RFC 3339 formatted timestamp strings (e.g., `"2023-05-01T14:30:00"`). To convert these values into actual timestamps, use an [expression](/import/advanced/table-mapping#expression-syntax) in the Stream's table mapping to parse the string and apply the appropriate time zone. ## Datalake representation Records are stored in your datalake, and delivered to your destination, as JSON. Each Prequel type has a stable JSON representation. | Prequel Type | JSON type | Representation | Example | | ------------ | -------------- | --------------------------- | ---------------------------------------------------- | | `bytes` | String | Base64 encoded string | `"aGVsbG8="` | | `string` | String | UTF-8 string | `"hello"` | | `boolean` | Boolean | JSON boolean | `true` | | `integer` | Number | JSON integer | `42` | | `bigint` | Number | JSON integer | `9223372036854775807` | | `decimal` | String | Numeric string | `"123.456789"` | | `float` | Number | Floating point number | `3.14159` | | `timestamp` | String | RFC 3339 formatted string | `"2023-01-01T14:30:00Z"` | | `date` | String | `YYYY-MM-DD` string | `"2023-01-01"` | | `time` | String | `HH:MM:SS.fffffffff` string | `"14:30:00.000000000"` | | `json` | Object / Array | Embedded JSON | `{"a": 1, "b": [2, 3]}` | | `geography` | Object | GeoJSON object | `{"type": "Point", "coordinates": [-122.41, 37.77]}` | | `vector` | Array | JSON array of numbers | `[0.1, 0.2, 0.3]` | **Decimals are represented as strings to preserve precision** Values of the `decimal` type are serialized as numeric JSON strings rather than JSON numbers. This prevents the loss of precision that would occur if high precision decimals were represented as floating point numbers. **Precision limitations for floating point and integer types** Floating point values are stored in IEEE 754 binary format, which cannot represent all decimal fractions exactly. To ensure accuracy, we **strongly recommend** using fixed precision types such as `decimal` instead. Integer values must fit within a signed 64-bit range. Values above `9223372036854775807` will overflow.