What event-driven workloads can OpenFaaS handle?

OpenFaaS can trigger functions from Apache Kafka, AWS SQS/SNS, GCP Pub/Sub, RabbitMQ, PostgreSQL, Cron, and MQTT, and it is built for asynchronous work such as ETL and data pipelines, batch jobs, and ML model runs. The fit is strongest when you need fan-out to many parallel executions, automatic retries, and queue-based scaling — including down to zero when idle. If your workload is a simple synchronous HTTP request, you do not need the event connectors at all.

Supported event sources

The OpenFaaS event connectors let you invoke functions from the following systems:

Each connector subscribes to the source and invokes your function when a message or event arrives, so you write the function logic rather than the plumbing.

Workload patterns that fit

ETL and data pipelines

The site describes processing large volumes of data where managing parallel execution, retries, and scaling is "a project in itself." With OpenFaaS you fan out to thousands of parallel function executions that scale automatically, and batch jobs run as functions with built-in retries — whether they take milliseconds or hours.

Batch and ML model runs

Long-running jobs are supported: functions can run for milliseconds or hours, with retries handled for you. This suits batch processing and ML model execution where a single run may be slow but many runs happen at once.

Multi-tenant code execution

If you want customers to extend your product with custom code, OpenFaaS turns code snippets into isolated functions built and deployed through a REST API. Each tenant runs in its own namespace with security boundaries enforced at every layer. The site names Waylay (IoT), LivePerson, Cognite (ML/data science), and RudderStack as production users.

Queue-based scaling

Surge is cited as running async jobs at scale — importing financial and government data to power background checks through Salesforce. This is the pattern to look at when you have a backlog of async jobs that must drain reliably.

What makes it work

• Scale to zero when idle. Functions scale down when there is no traffic, which matters for cost on bursty event workloads.
• Scale to meet demand. Pro features add autoscaling so parallel executions keep up with the event rate.
• Built-in retries. Async jobs are retried rather than silently dropped.
• Portable OCI images. Functions deploy on-premises or in the cloud with the same unified experience on any Kubernetes cluster.

Choosing between the free project and Pro

The event connectors and the core function model are the reason to use OpenFaaS for event-driven work. OpenFaaS Pro adds autoscaling, event connectors, monitoring dashboards, SSO, RBAC, and direct-to-engineering support. If you are running event-driven workloads in production and need autoscaling plus commercial support, evaluate Pro; the pricing page offers a free trial request. For a small internal pipeline, the open-source project may be enough — but confirm which connectors and scaling features you actually need before deciding.

When this is not the right fit

If your work is request/response with no queue, no schedule, and no event source, a plain HTTP function is simpler and the connectors add nothing. Event-driven OpenFaaS pays off when you have at least one of: a message broker or database feeding work in, a schedule, or a large fan-out of async jobs that must retry and scale.