Database

Why it's built in

Most of what a backend does is read or write data. Treating the database as a first-class part of the canvas — not an external service you configure once and then forget about — means you can see the shape of your data, browse real rows, and query them, in the same place you're designing the logic that uses them. No separate database GUI, no context-switching to check whether a migration actually ran.

Connecting a database

The Database node connects in two modes, set via its dbMode field:

• • local — a database managed for you, ready instantly, no connection string needed. Good for prototyping; not meant to be your production database.
• • remote — your own instance, picked via dbRemoteType: postgres, mysql, mongodb or sqlite, connected with a connection string kept in an Environment Variable — never typed directly onto the node.

Browsing your data

Switch to Database mode to get a full table view of a connected database right inside Fimaflow — inspect the schema, browse and edit rows directly, and run raw SQL from the built-in SQL console for anything a node doesn't cover (a one-off migration, an ad-hoc report query). Editing a cell commits immediately against the real database, so treat it the way you'd treat a production database client; inserting or deleting rows gets one safety net — those stay staged until you explicitly push them, covered below.

Inside Database mode

Database mode opens as a tabbed workspace, one tab per table you've looked at — a sidebar on the left lists every table in the connected database, with a search box to filter it once there are more than a handful.

• • Each row in the sidebar has its own menu: copy the table name, rename or duplicate it, export its data as CSV or JSON, or delete the table — all real operations against the database, not a local preview.
• • The toolbar above the grid filters rows across every column as you type, sorts by clicking a column header, and refreshes the current page.
• • A column's header menu lets you rename it or change its type (a real ALTER TABLE), or delete it outright. The Insert button adds a new column the same way, or a new row, or imports a CSV.

Editing a cell directly — click to select, double-click or Enter to edit, arrow keys to move between cells — commits immediately, the same way editing a spreadsheet cell would. Inserting or deleting whole rows works differently: a new row (typed by hand or dropped in from CSV import) shows amber and a row marked for deletion shows red, but neither actually happens until you click Push — giving you a chance to review a batch of changes, or an imported CSV, before it touches the real database.

Rows are paginated at 100 per page. For anything the grid doesn't cover — creating a table, a bulk migration, an arbitrary query — toggle the SQL button in the toolbar to get a console that runs directly against the same connection.

Querying with the SQL node

The SQL node runs a single statement, picked via sqlMethod:

• • SELECT (default) — returns an array of rows.
• • INSERT / UPDATE / DELETE — return a row count and, for INSERT, the inserted row's id.

A single call, wired to a table and a where clause built from data flowing through the workflow — reference an upstream value the same way anywhere else on the canvas, with {{fieldName}}:

SQL node
  method:  INSERT
  table:   orders
  values:  { sku: "{{sku}}", qty: "{{qty}}" }

Its output feeds directly into the next node — a validation error there gives you { error, code, query } instead of a raw driver exception, so a Try/Catch or a Response node downstream can act on it directly. See Debugging for what that looks like when a query fails mid-run.

Schema & migrations

The Schema node applies table changes — creating or migrating your database structure as part of a workflow, so schema changes stay versioned alongside the rest of your backend design instead of living in a separate migration tool you have to remember to run.

Working with the rest of the platform

• • Anything a query returns can flow straight into a Response node, transformed or as-is.
• • Wrap a multi-step write in a Transaction node when a failure partway through shouldn't leave the database half-updated.
• • An MCP-connected assistant can run read-only queries against the same database, without seeing the connection string.

Limitations

• • The local database is meant for prototyping — connect a remote one before relying on this for anything you can't afford to lose.
• • The SQL node runs one statement at a time; a multi-statement transaction needs a Transaction node wrapping several SQL nodes, not one SQL node with several statements.
• • Cell edits made from Database mode are immediate and unversioned — there's no undo beyond your database's own backups. Row inserts/deletes at least stay staged until you click Push.