PostgreSQL Error 42703: Column Does Not Exist (Fix Guide)

The Error Message

Look closely at that example — it explains the single most common cause of 42703. You wrote createdAt; the error complains about createdat, all lowercase. PostgreSQL silently lowercased your identifier before looking it up. If the error message shows a different casing than what you typed, you already know the fix: double quotes.

The #1 Cause: Unquoted camelCase Identifiers

PostgreSQL folds every unquoted identifier to lowercase (note: the SQL standard says uppercase — PostgreSQL deliberately differs, and Oracle folds to uppercase instead). So if your table was created with quoted camelCase columns — which is exactly what Prisma does by default, and what Sequelize does without underscored: true — the column is stored as createdAt with a capital A, and only the exact-case quoted form can reach it:

-- The table (as Prisma creates it):
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  "createdAt" TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- BAD: unquoted, PostgreSQL lowercases it to createdat
SELECT createdAt FROM users;
-- ERROR: column "createdat" does not exist

-- FIXED: double-quote mixed-case identifiers, exact case
SELECT "createdAt" FROM users;

This is why hand-written SQL, BI tools, and AI-generated queries break against ORM-created schemas: the application's ORM always emits the quotes, but anything outside the ORM forgets them. The reverse trap exists too — SELECT "CREATEDAT" fails because quoted identifiers must match the stored case exactly.

All Common Causes (Ranked)

Quick Diagnosis

Ask PostgreSQL for the column's exact stored name — case included:

-- The authoritative list (case shown exactly as stored):
SELECT column_name, data_type
FROM   information_schema.columns
WHERE  table_name = 'users'
ORDER  BY ordinal_position;

-- In psql:
-- \d users

-- Find a column by approximate name across all tables:
SELECT table_name, column_name
FROM   information_schema.columns
WHERE  lower(column_name) = lower('createdAt');

Decision rule: if column_name contains any uppercase character, you must double-quote it in every query. If it's all lowercase, never quote it and write it lowercase. Also read the error's HINT: line — PostgreSQL frequently names the column it thinks you meant, including the correct qualifier.

How to Fix It

Fix 1: Quote mixed-case identifiers (or stop creating them)

-- BAD:
SELECT id, createdAt, updatedAt FROM "Order";
-- ERROR: column "createdat" does not exist

-- FIXED (quote every mixed-case identifier, exact case):
SELECT id, "createdAt", "updatedAt" FROM "Order";

-- BEST long-term: migrate to snake_case so quoting is never needed
ALTER TABLE "Order" RENAME COLUMN "createdAt" TO created_at;
ALTER TABLE "Order" RENAME COLUMN "updatedAt" TO updated_at;
ALTER TABLE "Order" RENAME TO orders;

Note that MySQL behaves differently — column names there are case-insensitive on comparison, which is why queries ported from MySQL break on PostgreSQL. The MySQL counterpart of this error is Error 1054: unknown column.

Fix 2: Don't filter on a SELECT alias in WHERE

-- BAD:
SELECT price * quantity AS line_total
FROM   order_items
WHERE  line_total > 100;
-- ERROR: column "line_total" does not exist

-- FIXED (repeat the expression):
SELECT price * quantity AS line_total
FROM   order_items
WHERE  price * quantity > 100;

-- FIXED (CTE — alias becomes a real column for the outer query):
WITH totals AS (
  SELECT price * quantity AS line_total FROM order_items
)
SELECT * FROM totals WHERE line_total > 100;

Fix 3: Qualify with the correct table alias

-- BAD: total lives on orders
SELECT u.name, u.total
FROM   users u JOIN orders o ON o.user_id = u.id;
-- ERROR: column u.total does not exist
-- HINT: Perhaps you meant to reference the column "o.total".

-- FIXED:
SELECT u.name, o.total
FROM   users u JOIN orders o ON o.user_id = u.id;

Fix 4: Use single quotes for strings

-- BAD: double quotes make "active" an identifier
SELECT * FROM users WHERE status = "active";
-- ERROR: column "active" does not exist

-- FIXED:
SELECT * FROM users WHERE status = 'active';

Fix 5: Apply the missing migration

-- Confirm absence first:
SELECT 1 FROM information_schema.columns
WHERE  table_name = 'users' AND column_name = 'last_login_at';

-- Then run your migration tool, or:
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMPTZ;

ORM Gotchas: Prisma, Sequelize, TypeORM

• Prisma creates columns with the exact casing of your model fields — camelCase fields become quoted camelCase columns. prisma.$queryRaw and any external SQL must quote them. The clean fix: createdAt DateTime @map("created_at") plus @@map("users") on the model, keeping code camelCase and the database snake_case.
• Sequelize with default settings also creates camelCase columns. Set underscored: true (per model or globally) so createdAt maps to created_at.
• TypeORM ships a default naming strategy that preserves property casing; use SnakeNamingStrategy from typeorm-naming-strategies to get snake_case columns.
• BI tools / SQL editors / AI-generated SQL hitting an ORM-created schema are the classic 42703 factory: the schema has quoted camelCase columns and the generated SQL is unquoted. Either rename to snake_case once, or make sure every consumer quotes correctly.

How to Prevent This Error

Standardize on snake_case for everything in PostgreSQL — unquoted snake_case identifiers are immune to case folding. Configure your ORM's naming mapping on day one (@map / underscored: true / SnakeNamingStrategy) rather than retrofitting it. Verify column names against information_schema.columns before shipping raw SQL. And if your error is about the table rather than the column, see 42P01: relation does not exist — the same case-folding rules apply to table names. For parse-level failures, see 42601: syntax error.

Fix PostgreSQL Errors with AI2SQL

AI2SQL reads your actual schema — including quoted camelCase columns — and generates PostgreSQL queries with correct quoting automatically. Describe what you need in plain English and skip the case-folding archaeology.

Frequently Asked Questions