Quickstart

Install Feldera, create an incremental SQL pipeline, then query features from your serving layer. Estimated time: 10 minutes.

Before you start: You need Docker (20.10+) or Node.js 18+ installed. Feldera also provides a cloud-managed option at felderahq.com where no local setup is needed.

Step 1: Install

Pull the Feldera Docker image and start the runtime:

bash
docker pull feldera/feldera:latest
docker run -d \
  --name feldera \
  -p 8080:8080 \
  feldera/feldera:latest

Verify runtime is up:

bash
curl http://localhost:8080/health
# {"status":"ok","version":"0.9.2"}
Tip: You can also install the Feldera CLI with npm install -g @feldera/cli for a command-line workflow that wraps the same HTTP API.

Step 2: Set a pipeline

Create a pipeline configuration file listing input connectors, SQL transforms, and the feature outputs to serve.

yaml
name: txn-features
version: 1

connectors:
  - name: transactions
    type: kafka
    config:
      bootstrap_servers: "localhost:9092"
      topic: payments.transactions
      format: json

outputs:
  - name: card_velocity
    type: http
    key: card_id

Step 3: Write incremental SQL

Put standard SQL in a .sql file. Feldera compiles it into an operator graph that updates results incrementally when new events arrive.

sql
-- features.sql
CREATE VIEW card_velocity AS
SELECT
  card_id,
  COUNT(*) AS txn_count_1h,
  SUM(amount) AS spend_1h,
  COUNT(DISTINCT merchant_id) AS unique_merchants_1h,
  MAX(event_time) AS last_seen
FROM transactions
WHERE event_time > NOW() - INTERVAL '1 hour'
GROUP BY card_id;
Incremental vs re-scan: Feldera does not re-execute this query on a schedule. It compiles the SQL into an operator graph. When a new row lands from Kafka, only the affected aggregation state is updated. The full history is never re-scanned.

Step 4: Run the pipeline

Upload config and SQL, then start via the API:

bash
# Create the pipeline
curl -X POST http://localhost:8080/v1/pipelines \
  -H "Content-Type: application/json" \
  -d @pipeline.json

# Start it
curl -X POST http://localhost:8080/v1/pipelines/txn-features/start

Use the CLI:

bash
feldera pipeline create txn-features --config pipeline.yaml --sql features.sql
feldera pipeline start txn-features

Step 5: Query features

After startup, fetch feature values by key. Results include all events processed so far and update incrementally:

bash
curl http://localhost:8080/v1/features/txn-features/card_velocity/card_9182

# Response (sub-100ms)
{
  "card_id": "card_9182",
  "txn_count_1h": 7,
  "spend_1h": 412.50,
  "unique_merchants_1h": 4,
  "last_seen": "2026-07-10T14:22:38Z"
}
Latency: On internal benchmarks, feature reads return in under 5ms at the 99th percentile. Feature writes (from a new Kafka event to a queryable result) complete in under 100ms end-to-end.

Connectors

Feldera supports these input connectors by default:

Connector Type key Notes
Apache Kafka kafka JSON, Avro, Protobuf formats supported
PostgreSQL CDC postgres_cdc Uses logical replication slot (wal2json)
MySQL binlog mysql_cdc Row-level binlog events via Debezium
Amazon S3 s3 Batch bootstrap and S3 event notifications
HTTP POST http_push Push events directly via webhook endpoint

Core concepts

Incremental updates

Feldera compiles SQL into an operator graph, with each node storing the state needed for correct results as data arrives. A new event updates only affected nodes. No full-table scan or batch window is required.

Delta state

Every operator node stores changes as a delta, not a full snapshot. SUM and COUNT update by processing the new increment instead of the entire input relation.

Feature serving model

Running pipelines expose outputs as key-value pairs. Call GET /v1/features/{pipeline}/{view}/{key} for the current value for a key. For batch retrieval, use the scan endpoint to export every key at once.

Next: API Reference, covering endpoints and parameters.