# Use databases in workflows

Read and write records, filter rows, aggregate values, and react to database events without creating a loop.

## Plan availability

| Feature | Free | Starter | Pro | Enterprise |
| --- | --- | --- | --- | --- |
| Databases | Not included | 1 | 2 | Unlimited |
| Active workflows | 3 | 10 | 45 | Unlimited |

Allowances follow the [published Chatigram pricing page](https://chatigram.com/pricing/). Your organization’s Billing & Plans screen confirms its subscription and current usage. Plans can change. Plan information reviewed 2026-11-10.


## Choose the right operation

| Node | Use it when |
| --- | --- |
| Insert Database Row | You want a new record |
| Get Database Row | You already know the row ID |
| Find Database Rows | You need filters, sorting, or a list of matching records |
| Update Database Row | You want to change values in a specific record |
| Delete Database Row | You intend to remove a specific record |
| Summarize Database Rows | You need an aggregate result across selected records |

Select the destination database and table before configuring columns. Outputs and available filter fields depend on that table.

## Insert a request

After receiving the required inputs, add **Insert Database Row**. Map customer input to the appropriate columns. Use the inserted row ID to refer to that request later.

Columns left blank can be stored as empty values. Decide whether your workflow needs a condition that rejects incomplete requests before insertion.

## Search with filters

Use **Find Database Rows** and choose whether to match all conditions (**AND**) or any condition (**OR**). The supported comparison operators depend on the selected column type.

Text supports checks such as equals, contains, and starts with. Numeric fields support ordered comparisons. Empty checks are different from comparing with a literal word such as “empty”. System row ID and creation-time fields also have suitable comparisons.

Configure sorting when the order matters. Handle a search returning no records instead of assuming the first result exists.

## Update or delete deliberately

Fetch or identify the exact row, then pass its row ID to Update or Delete. Do not use a customer’s display name as if it were a unique row identifier.

Test writes on a disposable record. Retrying a run can repeat a previous insert, and deleting a row cannot be reversed by editor Undo.

## React to row changes

Choose **Database Operation** as the trigger. Select the database, table, and one or more operations: created, updated, or deleted.

For updates, use the available changed-fields and changes outputs to decide whether the event is relevant. Each change can describe the field, previous value, and next value.

> If the workflow updates the table it watches, check that the relevant value actually changed before writing again. Otherwise, one update can start another run repeatedly.

## Copy to another organization

For external notifications and supported AI subscriptions, see [database triggers and event monitoring](/data/database-events/). To connect your own business software, see the [REST API guide](/data/database-api/).

Review database, table, column, and filter selections after import. Choose destination resources explicitly. A copied definition does not copy the underlying records or transfer resource permissions.