Finding a specific column name across a sprawling database schema is a routine task for developers, database administrators, and data analysts. That said, whether you are debugging a legacy system, documenting an unfamiliar schema, or hunting for where a specific piece of data lives, knowing how to search for a column name in SQL efficiently saves hours of manual table inspection. The approach varies significantly depending on the database management system (DBMS) you are using, but the underlying principle remains the same: querying the system catalog or information schema metadata.
Understanding Database Metadata
Before diving into specific syntax, it is crucial to understand where this information lives. Every relational database maintains a set of system tables or views that describe the structure of the database itself. This is often referred to as the Data Dictionary or System Catalog Worth keeping that in mind..
No fluff here — just what actually works.
The ANSI-SQL standard defines the INFORMATION_SCHEMA, a standardized set of views (like COLUMNS, TABLES, VIEWS) that provide a consistent way to access metadata across different platforms. On the flip side, most major vendors also provide their own proprietary system catalog views (like sys.columns in SQL Server or all_tab_columns in Oracle) which often offer richer detail, such as data compression settings, partitioning info, or extended properties Most people skip this — try not to..
For maximum portability, INFORMATION_SCHEMA.COLUMNS is the safest bet. For deep administrative insight, native system views are superior Which is the point..
Searching in Microsoft SQL Server (T-SQL)
SQL Server offers two primary pathways: the standard Information Schema and the native sys schema.
Using INFORMATION_SCHEMA (Portable Method)
This view is readable and works across versions. It returns the table name, column name, data type, and nullability The details matter here..
SELECT
TABLE_SCHEMA,
TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
CHARACTER_MAXIMUM_LENGTH
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%CustomerID%'
ORDER BY TABLE_NAME, COLUMN_NAME;
Pro Tip: Always use the LIKE operator with wildcards (%) unless you know the exact casing and spelling. SQL Server collation settings determine case sensitivity, but LIKE is generally the most flexible approach.
Using sys.columns (Native Method)
The sys.columns catalog view is more performant on massive databases and exposes internal metadata like object_id, column_id, and is_identity. You must join it with sys.tables and sys.schemas to get human-readable names.
SELECT
s.name AS SchemaName,
t.name AS TableName,
c.name AS ColumnName,
ty.name AS DataType,
c.max_length,
c.precision,
c.scale,
c.is_nullable,
c.is_identity
FROM sys.columns c
INNER JOIN sys.tables t ON c.object_id = t.object_id
INNER JOIN sys.schemas s ON t.schema_id = s.schema_id
INNER JOIN sys.types ty ON c.user_type_id = ty.user_type_id
WHERE c.name LIKE '%Email%'
ORDER BY SchemaName, TableName;
This query reveals if a column is an identity column, its precise numeric precision/scale, and the specific schema owner—details INFORMATION_SCHEMA often obscures.
Searching in PostgreSQL
PostgreSQL adheres closely to the SQL standard. The information_schema.columns view is the primary tool, but the pg_catalog schema offers deeper system insight.
Standard Approach
SELECT
table_schema,
table_name,
column_name,
data_type,
character_maximum_length,
is_nullable
FROM information_schema.columns
WHERE column_name ILIKE '%order_date%'
ORDER BY table_schema, table_name;
Note the use of ILIKE instead of LIKE. PostgreSQL is case-sensitive by default; ILIKE performs a case-insensitive match, which is usually what you want during a search It's one of those things that adds up..
Advanced: Querying pg_attribute
For power users, pg_attribute stores column definitions for every relation (tables, views, indexes, sequences). This is faster but requires filtering out system columns (attnum > 0) and dropped columns.
SELECT
n.nspname AS schema_name,
c.relname AS table_name,
a.attname AS column_name,
t.typname AS data_type
FROM pg_attribute a
JOIN pg_class c ON a.attrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
JOIN pg_type t ON a.atttypid = t.oid
WHERE a.attnum > 0
AND NOT a.attisdropped
AND c.relkind IN ('r', 'v', 'm', 'f', 'p') -- tables, views, materialized views, foreign tables, partitioned tables
AND a.attname ILIKE '%user_id%'
ORDER BY schema_name, table_name;
Searching in MySQL and MariaDB
MySQL relies heavily on the INFORMATION_SCHEMA database. Because INFORMATION_SCHEMA is a database itself, you query it like any other And it works..
Basic Search
SELECT
TABLE_SCHEMA AS `Database`,
TABLE_NAME AS `Table`,
COLUMN_NAME AS `Column`,
DATA_TYPE AS `Type`,
COLUMN_TYPE AS `FullType`,
IS_NULLABLE AS `Nullable`,
COLUMN_KEY AS `Key`,
COLUMN_DEFAULT AS `Default`,
EXTRA AS `Extra`
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'your_database_name' -- Highly recommended for performance
AND COLUMN_NAME LIKE '%product_sku%'
ORDER BY TABLE_NAME, ORDINAL_POSITION;
Performance Note: In MySQL, querying INFORMATION_SCHEMA.COLUMNS without a TABLE_SCHEMA filter can be extremely slow on instances hosting hundreds of databases, as it may open table definition files (.frm or .sdi) to retrieve metadata. Always filter by TABLE_SCHEMA (database name) when possible.
Searching in Oracle Database
Oracle does not use INFORMATION_SCHEMA by default (though it can be enabled). Instead, it provides a reliable set of data dictionary views prefixed with USER_, ALL_, and DBA_.
USER_TAB_COLUMNS: Columns in tables owned by the current user.ALL_TAB_COLUMNS: Columns in tables accessible to the current user (most common for developers).DBA_TAB_COLUMNS: Columns in all tables in the database (requires DBA privileges).
Standard Developer Query
SELECT
OWNER,
TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
DATA_LENGTH,
DATA_PRECISION,
DATA_SCALE,
NULLABLE,
DATA_DEFAULT
FROM ALL_TAB_COLUMNS
WHERE COLUMN_NAME LIKE '%EMPLOYEE_ID%' -- Oracle identifiers are usually UPPERCASE
ORDER BY OWNER, TABLE_NAME, COLUMN_ID;
Critical Oracle Nuance: Unquoted identifiers in Oracle are stored in UPPERCASE. If you search for 'employee_id', you will find nothing. You must search for 'EMPLOYEE_ID' or use UPPER(COLUMN_NAME) LIKE '%EMPLOYEE_ID%'. If the column was created with quoted identifiers (e.g., CREATE TABLE t ("employee_id" INT)), it becomes case-sensitive, and you must match the exact case Simple as that..
Searching in SQLite
SQLite stores its schema in the sqlite_master table and