Your data

Database query

Database query reads rows straight from your own database (PostgreSQL, BigQuery or Snowflake) with one read-only SELECT, and turns each row into an item. Latitude and longitude columns become its position, so the blocks after it can search around your branches, sites or customers, add the weather, score them or map them. Fields from a webhook before it are passed in as values, never as part of the query.

In the editor: Reads rows from your own database with a SELECT query: PostgreSQL, BigQuery or Snowflake. Each row becomes an item (latitude and longitude columns become its position). Up to 5,000 rows, 20 seconds. The query runs on the server; the browser’s preview shows example rows.

Settings

Database

An account you connect

A PostgreSQL, BigQuery or Snowflake connection from the Connections page. Its Test button signs in for real; the sign-in is sealed and used only on the server.

Query

Text, several lines

SELECT only, one statement. {{field}} from a Webhook or app event before this block, and {{vars.name}}, are bound as parameters (a value can never change the query).

Needed before the flow can run.

At most

Pick one

The most rows to read each run. The query is wrapped so it never returns more than this.

  • 100 rows
  • 500 rows
  • 2,000 rows
  • 5,000 rows

What comes out

Each item that leaves the block carries these fields, to use in the blocks after it as {{field}}.

Each row

One item per row the query returns, with every column (up to 40).

  • (your columns): Each column, its name in lower case with spaces and symbols turned into underscores. Dates come as ISO text.
  • lat, lng: The position, from columns called latitude/longitude (or lon, long), when the query has them.
  • name: Guessed from title, company, customer, full_name, email or id when there is no name column.

How to use it

Banking and payments

Shops around each branch, mapped

A bank keeps its branches in PostgreSQL and wants a weekly map of the shops around each one.

The branches come in with positions, so Map business scan can search around each one.

Real estate

Plots under review, and what is around them

A property firm keeps its pipeline of plots in BigQuery and wants a weekly note on each plot’s surroundings.

Before: An analyst exported the plots and searched around each one by hand.

With the flow: Every Monday the land team reads one summary of all the plots under review.

Energy

Every station’s weather, each morning

The station list always comes from the database, so a new station is covered the morning after it is added.

Logistics

A depot’s customers on demand

A dispatcher’s tool calls a webhook with a depot name and wants that depot’s customers checked on the map.

The {{depot}} from the webhook is bound as a parameter, so a value can never change the query.

Retail

Stores that opened this quarter, and their competition

Filtering in SQL (opened in the last 90 days) keeps the flow small and fast.

Telecom

Tower sites and their nearest incidents

A telecom operator keeps its tower sites in Snowflake and wants to know which ones a road closure might cut off.

Before: Field teams found out about closures on the way to a site.

With the flow: Each hour the field team gets the sites with a closure nearby.

Good to know

  • One SELECT (or WITH ... SELECT) only: a second statement, or anything that changes data, is refused. PostgreSQL runs it in a read-only transaction; Snowflake is told to accept one statement; BigQuery is capped at 1 GB scanned by default.
  • Up to 5,000 rows, 40 columns and 20 MB, within 20 seconds. Past a limit the rows read so far come out and the step says what was cut.
  • {{field}} from a Webhook or app event before it, and {{vars.name}}, are bound as parameters ($1 in PostgreSQL, @p1 in BigQuery, ? in Snowflake). Only the first incoming item’s fields are used.
  • The database must be reachable on the public internet. PostgreSQL can require SSL; Snowflake needs a key pair to run live queries (a password alone is not enough).
  • The query runs on the server. The editor’s preview shows three example rows until then.
  • To check incoming items against a table rather than bring rows in, use Database lookup.
  • Free: reading your own database costs no credits.

Works well with

  • Database lookup: Looks each incoming item up in a table of your own database (PostgreSQL, BigQuery or Snowflake): your customers, your sites.
  • Map business scan: Finds businesses on online maps live: name, category, rating, address, phone, website and whether it is open.
  • Weather forecast: The weather forecast (Open-Meteo, from national weather services) for up to 16 days: temperature, rain, wind and UV.
  • Traffic incidents: Road closures, roadworks and other incidents on online maps right now, with where they are.
  • Show on a map: Shows the results as points on a map, with the area of interest.
  • Webhook / API: Starts the flow when another system sends a POST request with a JSON body to this flow’s webhook URL.
  • xMap LLM: Tell the AI what to do in plain words.
  • Filter: Keeps only the items that match a rule.

Help articles

Try it

Build a flow with Database query on the home page, no account needed, or book a call. Try it live