Components Platform

Parallelism Enabled by Default Across All Stacks

Starting June 2, 2026, parallelism is enabled by default for all component configurations across all Keboola stacks. The parallelism Off option is being removed. The new default is 1. You can set your own value before that date.

Starting June 2, 2026, parallelism is enabled by default for all component configurations across all Keboola stacks. This is a permanent change. The parallelism Off option is removed as part of this rollout.

What is changing?

For jobs that contain components with configuration rows, the default parallelism setting changes from Off to 1.

With parallelism Off, Keboola used a pipelined execution model where download and write steps could overlap between rows. With parallelism 1, rows are processed strictly one at a time. Each row must fully complete before the next one starts.

The Off option is no longer available. Parallelism 1 is the new minimum.

Who is affected?

This change affects all projects on all stacks that have components with configuration rows and currently use parallelism Off or have no parallelism setting configured.

Set your own value before June 2

You do not have to wait for the default to kick in. If you want to be in control of how your configurations behave, you can set parallelism yourself right now — on any configuration with configuration rows. Setting it explicitly before June 2 means the rollout will not change anything for you.

This is also a good opportunity to increase parallelism beyond 1 if you want more concurrency. Some examples of where higher parallelism has a meaningful impact:

  • Data Gateway — setting parallelism to match your row count means all data sources are pulled simultaneously. Data arrives in your BI tool faster and reporting is more up to date.
  • SQL database extractors (MySQL, PostgreSQL, MSSQL, Snowflake) — multiple tables or queries run at the same time instead of one by one, reducing overall extraction time.
  • Google BigQuery extractor — parallel extraction of multiple datasets or tables speeds up ingestion significantly for larger configurations.
  • BigQuery writer — writing multiple tables in parallel reduces the time your data spends in transit before it is available downstream.

In general, any component with multiple configuration rows benefits from parallelism. The more rows and the more independent they are, the greater the potential speed gain.

Possible impact

For most configurations, the practical impact is small. Based on analysis across our stacks prior to rollout:

  • The majority of configurations with configuration rows see no meaningful change in credit consumption.
  • Wall-clock time improves slightly on the median — jobs complete a little faster overall.

What do you need to do?

No action is required for most configurations. If you want to be in control, set parallelism explicitly on your configurations before June 2. If you want more concurrency, set it to a higher value.

Note that a queue limit can apply to concurrent jobs. If the number of running jobs exceeds the limit, additional jobs enter a waiting state.

For more details on how parallelism works and when to use it, see the documentation.

If you notice unexpected behavior in job execution after this change, please contact Keboola Support.