Editing Database Data
Work safely with live table rows in Database Manager: open a table, edit values, and understand when changes affect data instead of schema.
Introduction
Use this workflow when the table structure is already in place and the job is about row content, not columns or relations. Editing data in Database Manager is immediate and practical, but it should be treated differently from schema design because you are changing live records instead of preparing migrations.
Know what kind of change you are making
The main Database Manager tree is where both schema work and data work begin. Before opening an editor, decide whether you need to redesign the table itself or simply correct its current rows. That distinction prevents a common mistake: editing live data while thinking you are still in a safe schema-design phase.
Expand the real database branch first
Before you can reach a concrete table action, expand the working database branch so the actual table nodes are present in the tree. This keeps the next selection grounded in the live schema instead of assuming the whole tree is already open.
The working table behind the data editor
With the branch expanded, the tour can now select a real working table. In Demo Projects HQ, users is a stable example because it already backs login, profile, and permission flows elsewhere in the app.
The `View/Edit Data` context-menu entry
The selected table exposes its live record actions through this context menu. On a table like users, the menu surfaces View/Edit Data alongside other table-specific actions such as seed and template creation.
Close the menu before continuing
Close the context menu before moving on so the tree is readable again and the tour can switch back to explaining what the row editor is for.
What the row editor is for
Treat the data editor as a live records workspace. It is strong for checking seeded content, correcting wrong values, reviewing foreign-key results, and confirming what your forms or API actions really stored. It is not the place to redesign table shape, rename fields, or rethink relations.
Refresh before you trust what you see
If schema or data changed outside the current session, refresh first so the manager reflects the database accurately. This is especially important when you switch branches, pull teammate changes, or apply migrations elsewhere. A quick refresh reduces the chance of editing against stale assumptions.
Next steps
Return to the main Database Manager hub when you are ready for the next subject. From there you can continue into modeling, schema lifecycle work, or deeper reference coverage without losing your place.