How to Build Visual Data Pipelines with F-Pulse and Local Ollama Models

F-Pulse OSS is built for a specific workflow: design the pipeline visually, inspect the data at every step, and use AI assistance without sending schemas or prompts to a third-party API by default.

This guide walks through a local setup with F-Pulse OSS, Ollama, and qwen2.5:7b. The example pipeline reads application data, shapes it with SQL, validates the result, writes to a warehouse table, and schedules the run. The AI Copilot helps draft SQL and diagnose errors, but it never becomes the execution engine. The pipeline runtime still validates the graph, runs the nodes, and records the execution.

What you will build

The pipeline:

1. Reads recent orders from PostgreSQL
2. Joins customer metadata from a CSV file
3. Uses SQL to create a clean revenue fact table
4. Runs data quality checks
5. Writes the result to Postgres, DuckDB, Snowflake, BigQuery, or another supported destination
6. Sends a Slack notification when the scheduled run completes

F-Pulse OSS ships with 66 first-party connector types and is released under Apache 2.0. The local AI path uses Ollama by default, so your schema and pipeline context stay on the host unless you explicitly configure a cloud model provider.

Prerequisites

You need:

• Python 3.11+
• F-Pulse OSS
• Ollama
• A local model such as qwen2.5:7b
• A PostgreSQL database or sample CSV files

Install F-Pulse OSS from PyPI:

pip install fpulse
fpulse

Open the builder:

http://localhost:8001

Install Ollama and pull the local model:

ollama pull qwen2.5:7b
ollama run qwen2.5:7b

F-Pulse auto-detects Ollama on http://localhost:11434. In the app, open Settings > AI Providers, choose Ollama, and select qwen2.5:7b.

Step 1: Create the source connection

Open Connections and create a PostgreSQL connection. Use a read-only database user where possible.

For this guide, assume the source table is:

orders(
  id text primary key,
  customer_id text,
  order_ts timestamp,
  region text,
  status text,
  total_amount numeric
)

F-Pulse stores connection metadata separately from the pipeline graph. Credential handling stays inside your install, and F-Pulse+ adds vault-backed credentials and production controls for teams.

Step 2: Add the first node

Create a new pipeline and add a PostgreSQL Source node.

Configure it to read only the last day of complete orders:

SELECT
  id,
  customer_id,
  order_ts,
  region,
  status,
  total_amount
FROM orders
WHERE order_ts >= CURRENT_DATE - INTERVAL '1 day'
  AND status = 'paid'

Click Preview on the node. The important habit in F-Pulse is to preview as you build. You should see rows, inferred column types, and a JSON sample before you add downstream logic.

Step 3: Bring in a local file

Add a CSV Source node for customer metadata:

customer_id,segment,account_owner
c_001,enterprise,priya
c_002,midmarket,arun
c_003,startup,meera

Preview the node and confirm that customer_id, segment, and account_owner are detected correctly.

At this point you have two independent branches on the canvas: orders from Postgres and customer metadata from CSV.

Step 4: Ask the local Copilot for SQL

Add a SQL Transform node and connect both sources into it. Then ask the Copilot:

Join paid orders with customer metadata on customer_id.
Create daily revenue by region and segment.
Return report_date, region, segment, order_count, revenue, and avg_order_value.

With Ollama selected, the prompt is sent to the local model running on your machine. The Copilot should produce SQL similar to:

SELECT
  DATE_TRUNC('day', o.order_ts) AS report_date,
  o.region,
  COALESCE(c.segment, 'unknown') AS segment,
  COUNT(*) AS order_count,
  SUM(o.total_amount) AS revenue,
  AVG(o.total_amount) AS avg_order_value
FROM orders o
LEFT JOIN customers c
  ON o.customer_id = c.customer_id
GROUP BY 1, 2, 3

Review the generated SQL before saving it. The model is an assistant, not an authority. F-Pulse validates the node configuration and lets you preview the output before anything is scheduled.

Step 5: Validate the output

Add a Data Quality node after the transform.

Useful checks for this example:

• report_date is not null
• revenue >= 0
• order_count > 0
• avg_order_value >= 0
• segment is not null

Preview again. If the node fails, ask the Copilot to explain the validation failure. It can inspect the pipeline metadata, recent run state, and node errors through bounded tools. It does not need raw production data to explain common issues such as missing columns, type mismatches, or null spikes.

Step 6: Write to a destination

Add a destination node. Common options:

• Postgres sink for operational reporting
• DuckDB table for local analytics
• Snowflake, BigQuery, Redshift, or Databricks for warehouse teams
• S3, MinIO, ADLS Gen2, or GCS for Parquet output

For Postgres, write into:

daily_revenue_by_segment

Use report_date, region, and segment as the natural key for idempotent upserts. That makes the scheduled run safe to retry.

Step 7: Schedule and monitor

Add a daily schedule:

0 6 * * *

Set retry policy:

• 3 attempts
• Exponential backoff
• Alert on final failure

Add a Slack notification node for completion or failure. When the pipeline runs, F-Pulse streams execution logs over WebSocket and records the run history. You can click each node to inspect what happened instead of reading one long scheduler log.

Where Ollama helps most

Local models are most useful for:

• Drafting SQL transforms
• Explaining node failures
• Summarizing a pipeline
• Turning plain English into a draft pipeline
• Suggesting data quality checks
• Explaining connector configuration errors

Local models are not a replacement for runtime validation. F-Pulse keeps the execution path deterministic: the graph, connector configuration, SQL, retries, and schedules are all validated by the system before running.

When to use a cloud model instead

Ollama is the default because it preserves data sovereignty. Cloud models can still be useful when you explicitly opt in:

• Complex SQL rewrites across many tables
• Long-form incident summaries
• Architecture planning across many pipelines
• Deep reasoning over documentation

In those cases, configure a provider in Settings > AI Providers and use your own key. The important distinction is that cloud routing is an explicit operator choice, not the default behavior.

Production notes

F-Pulse OSS is enough for local development, solo operators, demos, and self-hosted pipeline building. For production teams, F-Pulse+ adds:

• 5-tier RBAC
• Approval gates
• Encrypted credential vault
• Audit retention
• SSO
• Worker pool controls

The same pipeline design moves forward; the production tier adds the controls around it.

Bottom line

Visual ETL and local AI work well together when the boundary is clear. Let the model draft, explain, and accelerate. Let the pipeline engine validate, execute, retry, monitor, and audit.

That is the F-Pulse pattern: visual pipeline design, live data preview, 66 connectors, Apache 2.0 OSS, and local AI through Ollama by default.

---

F-Pulse OSS is Apache 2.0 and self-hosted. Install it from the F-Pulse page, then connect Ollama locally to build private AI-assisted pipelines.