snowflake SQL compilation error: Object does not exist

TL;DR

Snowflake cant find the object because the fully qualified name is wrong: wrong database, wrong schema, wrong case, or the object was never created. Fully qualify as DATABASE.SCHEMA.OBJECT, check the session's current database and schema, and remember unquoted identifiers are uppercased.

snowflake SQL compilation error: Object does not exist

Use this when

• A Snowflake query fails with object does not exist
• An agent queries with a partial or wrong name
• The object exists but the query cant see it

Not for this skill when

• The error is about privileges (thats a grant problem)
• The warehouse is suspended or too small (thats compute)
• The SQL syntax itself is invalid (thats parsing)

Steps

1. Check what database and schema your session is using:

SELECT CURRENT_DATABASE(), CURRENT_SCHEMA();

Expected output: the session context. An unqualified orders resolves here; if the table lives elsewhere, this is the mismatch.

1. Fully qualify the object name:

SELECT * FROM ANALYTICS.PUBLIC.ORDERS LIMIT 10;

Expected output: the query works, or the error persists (which proves the object truly doesnt exist under that name).

1. Verify the object exists with the exact case:

SHOW TABLES LIKE 'ORDERS' IN SCHEMA ANALYTICS.PUBLIC;

Expected output: the table listed with its exact name. Snowflake uppercases unquoted identifiers, so a table created as "orders" (quoted lowercase) is invisible to ORDERS.

1. If it was created quoted-lowercase, quote it everywhere or rename:

SELECT * FROM ANALYTICS.PUBLIC."orders" LIMIT 10;

Expected output: rows return. Better long-term: rename to an unquoted name so nobody has to remember the quotes.

Variant phrasings

object exists in the UI but not in the worksheet

The UI and worksheet use different roles or different database contexts. Check CURRENT_ROLE() too; a role without USAGE on the schema gets the same "does not exist" message.

worked yesterday, fails today

Someone dropped/renamed the object, or the session context changed (a script that used to USE DATABASE first). Check both.

Why it happens

Snowflake resolves names against the session's current database, schema, and role. Any of those being wrong produces "object does not exist" even when the object is real, and the message deliberately doesnt say which part is wrong (or whether it is a permission issue). Agents generate queries with bare table names and no USE statements, so context mismatches are their top cause.

Edge cases

• Cloned databases: the object exists in the source but your session points at the clone, or vice versa.
• Reader accounts see only shared objects; the object may genuinely not exist in your account.
• Temporary tables vanish with the session; a temp table from yesterday's session is gone today.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tu7KWkWvD6iZOZcYUQvlTw