Keboola is a managed data platform that bundles extraction, transformation, orchestration, and storage into one hosted product. Rather than assembling an ingestion tool, a warehouse, an orchestrator, and a catalog yourself, you connect sources through prebuilt components, transform data with SQL or Python inside the platform, and schedule the whole thing with its built-in orchestrator. It targets teams that want a working data stack without operating the infrastructure - the components, the compute, and the storage backend are all run by Keboola.
Components, storage, and transformations
Work in Keboola flows through three layers. Extractors are prebuilt connectors that pull from APIs, databases, and files into Keboola Storage, a managed warehouse layer (backed by Snowflake, BigQuery, or similar). Transformations run SQL or Python against that storage to clean and model the data. Writers push results out to a BI tool, a warehouse, or another destination. Each step reads named input tables and produces output tables, and Keboola tracks the lineage between them.
| Layer | Role |
|---|---|
| Extractor | Prebuilt connector pulling a source into Storage |
| Storage | Managed warehouse layer holding input/output tables |
| Transformation | SQL or Python that models data inside the platform |
| Writer | Pushes results to BI, warehouse, or external systems |
Flows and orchestration
Keboola's orchestrator chains components into a flow: an ordered set of tasks with dependencies, run on a schedule or triggered via API. Because every component declares its input and output tables, the platform knows the data lineage end to end and shows it in a graph. A typical flow extracts from several sources in parallel, runs a sequence of SQL transformations, then writes to a dashboard tool - all defined in the UI and versioned by the platform.
# Conceptual shape of a Keboola flow
extract: [salesforce, stripe, google-analytics] # parallel
transform:
- stg_orders.sql # clean + cast
- dim_customer.sql # depends on stg_orders
- fct_revenue.sql # depends on dim_customer
write: [tableau] # final push
Where it fits
Keboola trades control for speed: you give up running your own ingestion and orchestration in exchange for a platform that has them ready. That suits smaller data teams or companies wanting a fast path to a governed warehouse. The tradeoffs are cost at scale and platform lock-in - pipelines built from Keboola components don't port directly to a self-hosted stack. Teams that need fine-grained control over orchestration, or already operate their own warehouse and scheduler, usually prefer assembling the stack themselves with a code-defined orchestrator like Dagster or Prefect.
Frequently asked questions
Is Keboola an ETL tool or an orchestrator? Both, plus storage. It bundles extractors, transformations, writers, and a flow orchestrator into one managed platform, so it covers the whole pipeline rather than one stage.
What warehouse does it use? Keboola Storage is backed by a cloud warehouse (commonly Snowflake or BigQuery), managed by the platform. Transformations run on that backend, and you can also read the data out.
Can I write custom logic? Yes. Beyond prebuilt components, transformations support SQL, Python, and R, and you can build custom components, so the platform isn't limited to its connector catalog.
What's the main tradeoff versus a self-hosted stack? Speed and low operational burden against cost at scale and platform lock-in. Pipelines are defined in Keboola's model and don't port directly to an open-source stack.