Database tools
Create, inspect and change native PostgreSQL objects in a joined workspace, with reviewed changes and dependency navigation.
Start in Database → Objects. Choose a Schema, then use Tables & views for records or Database tools for a particular kind of database object. Search applies to the schema and tool you selected. A link to an object restores its schema and tool; renaming or moving it preserves its PostgreSQL identity.
Find what you need
The selected object stays in the right pane:
- Overview puts the main controls first: ordered enum values, domain validation, composite fields, index state, trigger behavior or sequence settings. Object details and ownership sit beside that work.
- Definition shows available SQL for the object. Open it in SQL Editor for advanced changes. Functions, procedures, views and triggers support reviewed definition edits where PostgreSQL supports replacement.
- Usage separates objects that use the selected object from objects that it uses. Links open supported objects in the same workspace.
- Records, for tables and views, keeps filtering, pagination and record inspection in the same pane.
Usage comes from PostgreSQL's dependency catalogue. It does not discover references inside your application code, dynamic SQL or every function body. An empty Usage view is not proof that an application does not use the object.
Create and change objects
For schema changes you need to reproduce across environments, choose Migrations in the database header. Keep reviewed migration files in your repository and apply them with your release workflow. See Schema migrations.
Use Create below the object list. Its options follow the selected tool and schema. The public table editor and its relationship tools remain available through Tables & views.
| Object | Controls |
|---|---|
| Enum | Create a type; add a value at the end or before/after an existing value; rename a value; edit its description; rename or move the type; delete an unused type |
| Domain | Create a domain over a PostgreSQL type; change its default and nullability; add named validation checks; navigate to its check constraints |
| Composite type | Create with a first field; add fields; rename or change field types; delete fields |
| Table in another schema | Create with a primary key; add, change, rename or delete columns; filter and page records; review record inserts, updates and deletes |
| View | Create from a query; read records; review a replacement definition |
| Materialized view | Create from a query; read stored results; refresh its results |
| Function | Create SQL or PL/pgSQL functions; inspect typed arguments; edit supported definitions; review a test call and read its result table |
| Procedure | Create PL/pgSQL procedures; review execution with typed inputs; edit supported definitions |
| Index | Create an index on existing columns, including uniqueness and an optional partial condition; inspect its table, validity and method; rebuild it; inspect PostgreSQL size/scan statistics |
| Trigger | Create using an existing function returning trigger; inspect timing, event, table and execution state; enable or disable it; replace its definition |
| Constraint | Create check, unique and foreign-key constraints; inspect their table/domain; validate existing records; rename or delete a constraint |
| Sequence | Create; edit increment, bounds, cache and cycle behavior; explicitly restart at a reviewed value; inspect the last stored value without advancing it |
| Schema | Create; inspect and navigate its contents; rename it or delete an empty schema |
| Extension | Discover available trusted/non-superuser extensions; install one when your database role allows it; inspect version/provided objects; apply an available default update path; move relocatable extensions or delete an unused extension |
The public schema is retained for Fortly’s table and Data API editors; manage its contents here rather than renaming or deleting it through the workbench.
Supported objects also expose Object actions for descriptions, names, schema moves and deletion as PostgreSQL allows. Indexes backing constraints are deleted through their constraint rather than through an index delete action. PostgreSQL and extension-owned objects are protected from direct edits in this workbench.
Review and save
Owners and admins can apply object and record changes. Other workspace members can inspect the workbench.
Forms generate SQL for Review change. Nothing is written until you confirm Apply change. A multi-statement change commits as one transaction; a failure rolls it back. The server compares the reviewed object's current configuration with the review revision. If another editor changed it, refresh the review and check the SQL again. The refresh keeps entered form values when the object's identity and location still match.
A failed save keeps the draft and PostgreSQL's diagnostic. Closing an edited form asks whether to keep editing or discard the draft. Read and lock timeouts return control to the editor; refresh before retrying a timed-out write.
Renaming, moving or deleting a public table/function through the workbench clears API grants for its old identity and invalidates pending API-role reviews. A new object reusing the old name starts without those grants. Re-review Data API after the change. Revocation happens before the database commit so a commit failure leaves access closed; re-enable the intended grants explicitly after recovery. SQL Editor and external migrations retain their existing access semantics and require their own permission review.
Deletes use PostgreSQL RESTRICT; the workbench never silently cascades deletion into dependent objects. Dropping a table or column still removes the data it owns. A foreign key's configured ON DELETE and ON UPDATE behavior applies to record changes.
Record editing
Native table record edits use every primary-key column and an original-row version. If the record changed after you opened it, the server rejects the write; reopen the latest record before trying again. Tables without a primary key can be read and inserted into, but their edit/delete actions are unavailable.
Identity/generated fields, database defaults, empty text and SQL NULL have distinct controls. Numeric and bigint inputs retain their text representation. Native record queries return JSON and array fields as exact JSON text so a preview does not round their numeric values.
Views, materialized views and foreign tables are read-only in this Records editor. PostgreSQL may support specific writes through views or foreign data wrappers; use SQL Editor or a database client for those cases.
PostgreSQL limits
Existing enum values cannot be deleted or reordered in place. Renaming a label updates the label everywhere that enum value is stored; inserting a new value can select its sort position.
Index creation/rebuild, constraint validation and materialized-view refresh can hold locks. The reviewed actions use ordinary transactional operations with bounded statement/lock waits. Use SQL Editor or a database client when you need a concurrent index operation or a longer maintenance window.
Function/procedure test calls run with the project database owner's privileges and can change data. They are distinct from testing an application identity through Data API → API explorer. Function array arguments use JSON arrays. Procedure array arguments use PostgreSQL array input syntax, shown in the field help. Trigger-returning functions execute through their trigger rather than as ordinary function calls. Polymorphic/internal signatures and anonymous record results without declared output columns use SQL Editor, where you can supply concrete argument/result types. Procedures that require transaction control need an appropriate PostgreSQL client session.
Aggregate definitions, foreign-data-wrapper configuration, arbitrary base types and other specialized PostgreSQL features remain available through native SQL. The install picker omits packages that require an untrusted superuser installation. Extensions install into the selected schema unless their package requires a fixed schema. Availability still does not guarantee that the managed role can complete installation; PostgreSQL enforces its privilege requirements.