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). Edits made here happen immediately against the real database — there's no draft/apply step, so treat it the way you'd treat a production database client.

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.
• • Row edits made from Database mode are immediate and unversioned — there's no undo beyond your database's own backups.