Rename Table in PostgreSQL

Renaming a table in PostgreSQL uses ALTER TABLE ... RENAME TO. Unlike some databases, PostgreSQL automatically propagates the name change to all dependent objects — foreign key constraints, views, and rules are updated transparently. The rename acquires a brief ACCESS EXCLUSIVE lock but does not rewrite any data.

Syntax

ALTER TABLE table_name RENAME TO new_table_name;

To avoid an error when the table may not exist:

ALTER TABLE IF EXISTS table_name RENAME TO new_table_name;

There is no syntax to rename multiple tables in a single statement — issue separate ALTER TABLE ... RENAME TO statements for each.

Practical Example

Create a table with dependent objects, then rename it:

CREATE TABLE suppliers (
  supplier_id  SERIAL PRIMARY KEY,
  company_name VARCHAR(200) NOT NULL,
  country      VARCHAR(100) NOT NULL
);

CREATE TABLE purchase_orders (
  po_id       SERIAL PRIMARY KEY,
  supplier_id INT NOT NULL,
  total       NUMERIC(12,2) NOT NULL,
  FOREIGN KEY (supplier_id) REFERENCES suppliers(supplier_id)
    ON DELETE RESTRICT ON UPDATE CASCADE
);

CREATE VIEW supplier_summary AS
SELECT
  s.supplier_id,
  s.company_name,
  COUNT(p.po_id) AS order_count
FROM suppliers s
LEFT JOIN purchase_orders p USING (supplier_id)
GROUP BY s.supplier_id, s.company_name;

-- Rename the table
ALTER TABLE suppliers RENAME TO vendors;

After the rename, verify the foreign key and view were updated automatically:

-- Foreign key now references "vendors"
\d purchase_orders

Foreign-key constraints:
    "purchase_orders_supplier_id_fkey" FOREIGN KEY (supplier_id) REFERENCES vendors(supplier_id)

-- View definition updated automatically
\d+ supplier_summary

Check what was NOT renamed — the sequence and index keep the original prefix:

\d vendors

Default: nextval('suppliers_id_seq'::regclass)
Indexes:
    "suppliers_pkey" PRIMARY KEY, btree (supplier_id)

Rename the sequence and index separately for consistency:

ALTER SEQUENCE suppliers_id_seq RENAME TO vendors_id_seq;
ALTER INDEX suppliers_pkey RENAME TO vendors_pkey;

What Renames Automatically vs. Manually

Testing with Vela

Renaming a table is one of the riskiest schema changes for an active application — any hardcoded table name in queries, ORM models, or stored procedures will break immediately. Vela database branching lets you rename the table on a branch and point your test environment at it to surface every reference that needs updating before the rename hits production.

Production Tips

• Renaming a table is metadata-only — no data is rewritten, making it fast even on very large tables.
• Application code and ORM models that reference the old table name will break immediately after the rename. Update and deploy them in the same release window.
• SERIAL sequences keep the old name prefix after the rename. Rename them with ALTER SEQUENCE old_seq RENAME TO new_seq if naming consistency matters.
• Index names also retain the original prefix. Rename with ALTER INDEX old_idx RENAME TO new_idx.
• Always test renames in a staging environment or Vela branch before applying to production.