Troubleshooting Snowflake errors

TL;DR

Resolve common Snowflake errors when querying Lakehouse Iceberg tables and Polaris catalog-linked databases, including tables that are missing because they hold no data.

Your AI can read this via Docs MCPcurl -fsSL "https://docs.atlan.com/install-docs-mcp" | bashConnect

When querying Lakehouse Iceberg tables or Polaris catalog-linked databases from Snowflake, you may encounter errors related to table initialization, object resolution, or tables that aren't listed. This page covers the most common errors and how to fix them.

Table isn't initialized

Error

SQL Compilation Error: table '<table_name>' is not initialized

GCP-hosted tenants only

This issue only affects Snowflake users whose Atlan tenants are deployed on Google Cloud Platform (GCP).

When querying Lakehouse Iceberg tables stored on Google Cloud Storage (GCS) from Snowflake, you may encounter a SQL compilation error stating that the table isn't initialized. This happens when the required GCS external volume and Polaris catalog integration aren't configured in Snowflake.

Cause

Snowflake requires an external volume to authenticate and access files stored in GCS. Without this configuration, Snowflake can't read the Iceberg metadata files needed to initialize the table.

When a Lakehouse Iceberg table is registered in Snowflake without a properly configured GCS external volume and Polaris catalog integration, Snowflake treats the table as uninitialized because it can't resolve the table's metadata location. In this setup, Atlan owns and manages the GCS bucket for metadata storage, while you own and manage the Snowflake account that accesses the data.

Solution

Get required information from Atlan: Contact Atlan to obtain the GCS bucket name, the GCS prefix within the bucket, and the Polaris reader ID and reader secret.
Create a GCS external volume: In your Snowflake account, create an external volume pointing to the Atlan GCS bucket. Replace <volume-name>, <storage-location-name>, <gcs-bucket-name>, and <gcs-prefix> with your values:
```
CREATE EXTERNAL VOLUME <volume-name>
  STORAGE_LOCATIONS = (
    (
      NAME = '<storage-location-name>'
      STORAGE_PROVIDER = 'GCS'
      STORAGE_BASE_URL = 'gcs://<gcs-bucket-name>/<gcs-prefix>/'
    )
  )
  ALLOW_WRITES = FALSE;
```
Retrieve the Snowflake GCP service account by running DESC EXTERNAL VOLUME <volume-name>; and note the STORAGE_GCP_SERVICE_ACCOUNT value.
Request GCS bucket access from Atlan: Share the service account with Atlan. Atlan grants read-only access to the GCS bucket. Once Atlan confirms access, verify Snowflake can reach the bucket:
```
SELECT SYSTEM$VERIFY_EXTERNAL_VOLUME('<volume-name>') AS status;
```

Create a catalog integration: Create a catalog integration that connects Snowflake to the Lakehouse Polaris catalog. Replace <catalog-name> with a descriptive name, <tenant-subdomain> with your Atlan tenant subdomain, and the Polaris credential placeholders with the values from step 1:

CREATE OR REPLACE CATALOG INTEGRATION <catalog-name>
  CATALOG_SOURCE = POLARIS
  TABLE_FORMAT = ICEBERG
  CATALOG_NAMESPACE = 'atlan-ns'
  REST_CONFIG = (
    CATALOG_URI = 'https://<tenant-subdomain>.atlan.com/api/polaris/api/catalog'
    WAREHOUSE = 'atlan-wh'
    ACCESS_DELEGATION_MODE = VENDED_CREDENTIALS
  )
  REST_AUTHENTICATION = (
    TYPE = OAUTH
    OAUTH_CLIENT_ID = '<polaris-reader-id>'
    OAUTH_CLIENT_SECRET = '<polaris-reader-secret>'
    OAUTH_ALLOWED_SCOPES = ('PRINCIPAL_ROLE:lake_readers')
  )
  REFRESH_INTERVAL_SECONDS = 900
  ENABLED = TRUE;

Create a catalog-linked database: Create a database linked to the catalog integration. This lets Snowflake automatically sync and access the Lakehouse Iceberg tables:

CREATE DATABASE <database-name>
  LINKED_CATALOG = (
    CATALOG = '<catalog-name>',
    SYNC_INTERVAL_SECONDS = 10800
  )
  EXTERNAL_VOLUME = '<volume-name>';

Verify tables are accessible: Once the database is created, Snowflake automatically syncs the tables. Verify the sync state and then query the Lakehouse Iceberg tables through the linked database:
```
SELECT SYSTEM$CATALOG_LINK_STATUS('<database-name>');
```

Object doesn't exist

Error

Object does not exist

When querying Polaris catalog-linked databases from Snowflake, you may see Object doesn't exist errors even though the table or view clearly exists. This is caused by the Snowflake session parameter QUOTED_IDENTIFIERS_IGNORE_CASE being set to TRUE.

Snowflake has confirmed this as a known limitation that affects catalog-linked databases with lowercase object names.

You are likely hitting this issue if:

You are querying a Polaris catalog-linked database from Snowflake.
Your query uses double-quoted identifiers for tables or columns, including reserved keywords. For example:
```
SELECT *
FROM context_store.entity_metadata."table";
```
The object exists in Polaris and works from other engines, but Snowflake returns Object does not exist or similar resolution failures.

Different cause: missing grants

If your role hasn't been granted access to the context_store database, Snowflake returns Object does not exist or not authorized—the same error, but with a different cause. Confirm the role has the grants described in Grant access to Lakehouse tables before troubleshooting case sensitivity.

Cause

The Snowflake session parameter QUOTED_IDENTIFIERS_IGNORE_CASE is set to TRUE. With this setting, Snowflake treats double-quoted identifiers as case-insensitive and uppercases them during object resolution.

Polaris stores object names in lowercase. When Snowflake uppercases the identifier (for example, "table" becomes TABLE), the lookup in the Polaris catalog-linked database fails, even though table exists in lowercase.

This issue is especially visible when tables or columns are named using reserved SQL keywords (such as "table", "group", or "order") that are stored in lowercase in Polaris.

Solution

Before querying any Polaris catalog-linked database from Snowflake, disable QUOTED_IDENTIFIERS_IGNORE_CASE in your session:

ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = FALSE;

Run this as the first statement in your Snowflake session—including BI tools, notebooks, and worksheets—before querying any catalog-linked database.

No special permissions required

ALTER SESSION SET doesn't require any elevated privileges. Any Snowflake user can modify their own session parameters, even if the parameter is set to TRUE at the account level.

Example session setup

-- Ensure quoted identifiers remain case-sensitive
ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = FALSE;

-- (Optional) Set role, database, and schema as usual
USE ROLE ACCOUNTADMIN;
USE DATABASE <your_catalog_linked_database>;
USE SCHEMA <your_schema>;

-- Queries against Polaris catalog-linked objects now resolve correctly
SELECT *
FROM context_store.entity_metadata."table";

Configuration notes

The parameter can be set at the account, user, or role level. Even if it's globally TRUE, you can override it per session with:
```
ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = FALSE;
```
This setting is safe for other databases. Snowflake's default is FALSE, and leaving it FALSE keeps the usual SQL behavior where unquoted identifiers are uppercased and double-quoted identifiers are case-sensitive.
If you control Snowflake account-level configuration, consider keeping QUOTED_IDENTIFIERS_IGNORE_CASE = FALSE as the default for roles that access Polaris catalog-linked databases.

This workaround remains necessary until Snowflake ships a permanent fix for catalog-linked database behavior.

Table is missing from Snowflake

Error

SQL compilation error: Object '<table_name>' does not exist or not authorized

You are likely hitting this issue if:

The missing table is for an asset type, feature, or namespace that has no data in your Atlan tenant yet. For example, the entity_metadata."airflowdag" table when you don't use Airflow, or the usage_analytics."ai_tool_calls" table before anyone has used Atlan AI.
The same table is visible from another query engine, such as PyIceberg, DuckDB, Databricks, or BigQuery.
A view or script that unions many entity_metadata tables started failing without any change on your side.

Cause

The table isn't listed in your catalog-linked database because it holds no rows. SHOW ICEBERG TABLES returns fewer tables than the Lakehouse namespace contains, views or scheduled tasks that reference the missing table fail, and SYSTEM$CATALOG_LINK_STATUS reports RUNNING with no failure details because the link itself is healthy.

Snowflake discovers and refreshes Lakehouse tables by polling Atlan's Iceberg REST Catalog on a schedule. Every Atlan tenant has a table for every asset type in the metamodel, and most tenants use only a fraction of those types. Polling hundreds of tables that hold no rows adds load on both sides without returning any data.

As of September 1, 2026, the Lakehouse materializes only tables that contain data in Snowflake. Tables with zero rows aren't registered in your catalog-linked database, and empty tables that Snowflake had already mirrored were dropped from it. Your data isn't affected: the table still exists in the Lakehouse, it just has no rows.

This behavior is specific to the Snowflake catalog integration. Other query engines continue to list every table, including empty ones.

Tables in the entity_metadata, usage_analytics, and observability namespaces are the most commonly affected, because they contain one table per asset type or feature and many of those are empty on a typical tenant.

Solution

You don't need to change anything in Snowflake. A table appears in your catalog-linked database automatically once it holds at least one row. The Lakehouse caches whether a table is empty for up to 6 hours, and Snowflake then discovers new tables on its own SYNC_INTERVAL_SECONDS schedule, so a table that has just received data can take several hours to appear.

To keep your queries working as tables come and go:

Check the catalog before referencing a table. Don't hardcode table names that may be empty on your tenant. List what Snowflake has registered and build your query from that:
```
-- Tables Snowflake currently has for a namespace
SHOW ICEBERG TABLES IN SCHEMA context_store.entity_metadata;

-- Or query the information schema
SELECT table_name
FROM context_store.information_schema.tables
WHERE table_schema ILIKE 'entity_metadata';
```
Snowflake stores catalog-linked identifiers in lowercase, so keep the ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = FALSE; workaround from Object doesn't exist in place when you quote table names.
Use the gold namespace instead of rebuilding it. If you maintain views or tasks that UNION every entity_metadata table into a combined assets table, replace them with the pre-built tables in the gold layer. The gold tables already combine all asset types, so they don't break when an individual type has no assets.
Confirm the table is empty rather than missing. If you believe a missing table must contain data, query it from another engine or check the asset type in Atlan. If the table has rows in the Lakehouse but still doesn't appear in Snowflake after the next sync interval, contact Atlan Support.

Need help

If you need assistance after trying these steps, contact Atlan support.

Table isn't initialized​

Cause​

Solution​

Object doesn't exist​

Cause​

Solution​

Example session setup​

Configuration notes​

Table is missing from Snowflake​

Cause​

Solution​

See also​

Need help​

Table isn't initialized

Cause

Solution

Object doesn't exist

Cause

Solution

Example session setup

Configuration notes

Table is missing from Snowflake

Cause

Solution

See also

Need help