Table has more than 1600 columns, exceeding PostgreSQL's practical column limit Index row size exceeds the maximum (typically ~2712 bytes), often from indexing large text columns Query or procedure exceeds maximum stack depth (default 2MB via max_stack_depth)

Is the "54000" error serious?

Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

How to fix Configuration limit exceeded in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 28, 2025· 137 views

PostgreSQL configuration limit exceeded error (54000) occurs when a predefined system limit is surpassed, such as maximum table columns, function arguments, or query complexity. Fix by refactoring your schema or query design rather than adjusting compiled limits.

Quick fix

Fixes 54000

ERROR: index row size 4496 exceeds maximum 2712
ERROR: row is too big: size 8192, maximum size 8160
ERROR: stack depth limit exceeded

Check the specific limit error message
For table width issues (too many columns)
For oversized index keys
For stack depth issues in queries or procedures

postgresql — error

$ERROR: index row size 4496 exceeds maximum 2712
ERROR: row is too big: size 8192, maximum size 8160
ERROR: stack depth limit exceeded
Configuration limit exceeded

What this error means

PostgreSQL enforces hard-coded limits on various configuration parameters to maintain system stability and prevent resource exhaustion. When you exceed these limits—such as table width, recursion depth, or index size—the database returns error 54000 (program_limit_exceeded). Unlike soft limits like max_connections that can be adjusted in postgresql.conf, configuration limits are compiled into PostgreSQL and cannot be changed through configuration alone.

Typical symptoms

Database operations fail with "ERROR: 54000 configuration_limit_exceeded"
Error message includes specific limit details (e.g., "index row size 4496 exceeds maximum 2712")
Certain queries or data modifications work on smaller datasets but fail at scale
Table creation fails when attempting to add too many columns or indexed fields

Common causes

Table has more than 1600 columns, exceeding PostgreSQL's practical column limit
Index row size exceeds the maximum (typically ~2712 bytes), often from indexing large text columns
Query or procedure exceeds maximum stack depth (default 2MB via max_stack_depth)
GROUPING SETS clause with hundreds of elements in complex queries
CREATE INDEX on very wide tables with large data types in the index key
Recursive queries or functions with excessive call stack depth

How to fix "Configuration limit exceeded"

1Check the specific limit error message

The error will include details about which limit was exceeded. Common formats:

bash

ERROR: index row size 4496 exceeds maximum 2712
ERROR: row is too big: size 8192, maximum size 8160
ERROR: stack depth limit exceeded

Note the specific limit mentioned to determine which solution applies.

2For table width issues (too many columns)

If you have a table with many columns, split it into multiple related tables:

sql

-- Move rarely-accessed columns to a separate table
CREATE TABLE users_extended (
  user_id INTEGER REFERENCES users(id),
  profile_data TEXT,
  preferences JSONB
);

-- Query across tables when needed
SELECT u.*, ue.profile_data FROM users u
LEFT JOIN users_extended ue ON u.id = ue.user_id;

PostgreSQL efficiently handles 1600 columns per table; split wider tables.

3For oversized index keys

Instead of indexing the entire large column directly, create a functional index or use full-text search:

sql

-- Problem: Indexing large text column
CREATE INDEX idx_large_text ON documents(body); -- May fail

-- Solution 1: Hash the value
CREATE INDEX idx_body_hash ON documents(md5(body));

-- Solution 2: Use full-text search index (more efficient)
CREATE INDEX idx_body_fts ON documents USING GIN(to_tsvector('english', body));

-- Query with full-text search
SELECT * FROM documents 
WHERE to_tsvector('english', body) @@ to_tsquery('english', 'your:query');

4For stack depth issues in queries or procedures

Rewrite recursive logic to use iterative approaches or WITH RECURSIVE CTEs:

sql

-- Problem: Deep recursion
CREATE OR REPLACE FUNCTION find_children(id INT) RETURNS TABLE(child_id INT) AS $$
BEGIN
  RETURN QUERY SELECT child_id FROM items WHERE parent_id = id;
  RETURN QUERY SELECT * FROM find_children(child_id);
END;
$$ LANGUAGE plpgsql;

-- Solution: Use WITH RECURSIVE CTE
WITH RECURSIVE hierarchy AS (
  SELECT id, parent_id FROM items WHERE parent_id = $1
  UNION ALL
  SELECT i.id, i.parent_id FROM items i
  INNER JOIN hierarchy h ON i.parent_id = h.id
)
SELECT id FROM hierarchy;

Recursive CTEs are more efficient and avoid stack depth issues.

5For complex queries with GROUPING SETS

Break down complex aggregations into separate queries or use UNION ALL:

sql

-- Problem: Too many grouping sets
SELECT col1, col2, col3, col4, COUNT(*)
FROM table1
GROUP BY GROUPING SETS (
  (col1, col2, col3, col4),
  (col1, col2, col3),
  (col1, col2),
  (col1),
  ()
);

-- Solution: Separate simpler queries
SELECT col1, col2, col3, col4, COUNT(*) FROM table1
GROUP BY col1, col2, col3, col4
UNION ALL
SELECT col1, col2, col3, NULL, COUNT(*) FROM table1
GROUP BY col1, col2, col3;

Advanced notes

PostgreSQL's configuration limits are hard-coded during compilation and cannot be changed via postgresql.conf adjustments. On managed platforms (Heroku, AWS RDS), you typically cannot recompile PostgreSQL, making schema refactoring the only practical solution. The max_stack_depth parameter can be increased on self-hosted PostgreSQL (HINT message shows current value), but this requires platform ulimit coordination—on managed services this is often impossible. Always prefer schema redesign over trying to bypass compiled limits. Consider using TOAST (The Oversized-Attribute Storage Technique) for large text/bytea columns, which stores oversized data separately from main tuples and avoids bloating indexes.

Frequently asked questions

What does "54000" mean?: PostgreSQL enforces hard-coded limits on various configuration parameters to maintain system stability and prevent resource exhaustion. When you exceed these limits—such as table width, recursion depth, or index size—the database returns error 54000 (program_limit_exceeded). conf, configuration limits are compiled into PostgreSQL and cannot be changed through configuration alone.
How do I fix "54000"?: PostgreSQL configuration limit exceeded error (54000) occurs when a predefined system limit is surpassed, such as maximum table columns, function arguments, or query complexity. Fix by refactoring your schema or query design rather than adjusting compiled limits.
What causes "54000"?: Table has more than 1600 columns, exceeding PostgreSQL's practical column limit Index row size exceeds the maximum (typically ~2712 bytes), often from indexing large text columns Query or procedure exceeds maximum stack depth (default 2MB via max_stack_depth)
Is the "54000" error serious?: Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.