Add column
Append a new column to an existing table with the specified type and constraints.
ALTER TABLE public.customers
ADD COLUMN phone TEXT;Illustrative SQL - not executed
Platform capability
Stage schema modifications, inspect the generated SQL or command, and apply only after reviewing the exact change against the target connection.
Schema change support depends on the connected database engine and permissions. Review the generated command and target before applying changes. Not all engines support all change types.
Schema change review
Table / public.customers
Proposed change - not yet applied
Illustrative table structure only
Generated DDL
ALTER TABLE public.customers
ADD COLUMN phone TEXT;Sample schema change -- no live execution
DDL auto-commit warning
Some engines auto-commit DDL statements. Review the command and target connection before applying. Rollback may not be available.
Illustrative interface - all controls disabled
Schema changes in SyneHQ follow the same stage-review-apply workflow as data mutations. Propose a structural change, inspect the generated DDL statement, confirm the target connection, and apply only after reviewing what will run.
Schema modifications are staged from the Data Explorer's schema workspace. When you propose a change -- adding a column, renaming a field, creating an index -- SyneHQ generates the corresponding DDL statement for the connected engine and displays it in the review panel before anything executes.
The review surface shows the full generated command, the target table and connection, and the type of operation. Use this to confirm the object, the change, and the engine before applying. DDL on many engines auto-commits and cannot be rolled back inside a transaction, so the review step is the point where you catch a misplaced ALTER or wrong target.
Cancel from the review panel to discard a staged change without executing it.
The set of schema changes available depends on the connected database engine and your permissions. Common operations include adding or dropping columns, renaming columns, and adding or removing indexes. Not every engine supports every change type, and some engines impose restrictions on certain alterations (for example, SQLite limits in-place column changes).
The generated command reflects what the engine actually requires. A column addition on PostgreSQL produces an ALTER TABLE ... ADD COLUMN statement; the same logical change on another engine may produce a different command or may not be available at all.
Supported change types
Available operations depend on the connected engine and permissions. These illustrative examples show PostgreSQL DDL.
Append a new column to an existing table with the specified type and constraints.
ALTER TABLE public.customers
ADD COLUMN phone TEXT;Illustrative SQL - not executed
Change a column name while preserving its type and data. Engine support varies.
ALTER TABLE public.orders
RENAME COLUMN status
TO order_status;Illustrative SQL - not executed
Create an index on one or more columns to support query performance.
CREATE INDEX idx_orders_created
ON public.orders (created_at);Illustrative SQL - not executed
Remove a column and its data from the table. This change is destructive.
ALTER TABLE public.customers
DROP COLUMN legacy_ref;Illustrative SQL - not executed
Each schema change targets a specific connection and object. The generated DDL is scoped to that connection's engine dialect, so the same logical change can look different across PostgreSQL, MySQL, MongoDB, or other supported engines.
Review the target connection name and engine type in the review panel before applying. If the wrong connection is selected, the generated command may reference an object that does not exist or behave differently than expected on the intended engine.
Permissions also apply: a change that your database role cannot execute will fail at apply time regardless of what the review panel shows. Confirm your role's DDL privileges on the target before applying structural changes.