> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/concepts/resources/vulcan/components/model/types.md). # Types Vulcan supports multiple model types for different execution patterns. Choose the type that matches how your data is defined, executed, and maintained. ## What this section covers Use this section when you need to: * decide between SQL and Python models * reference data that Vulcan does not manage * use engine-managed refresh behavior * understand the tradeoffs between model definitions ## Quick selection guide Start with **SQL models** for most projects. Use **Python models** when SQL is not enough. Use **External models** when you need metadata for tables outside the project. Use **Managed models** when the engine should refresh data automatically. ## Compare model types | Type | Best for | Managed by Vulcan | Query required | | ---------- | --------------------------------------------------- | :---------------: | :------------: | | `SQL` | Standard transformations and warehouse-native logic | Yes | Yes | | `Python` | API calls, ML workflows, complex procedural logic | Yes | No | | `EXTERNAL` | Schema metadata for external tables | No | No | | `MANAGED` | Engine-driven refresh for supported platforms | Partly | Yes | {% hint style="info" %} Most projects rely mainly on SQL models. Add other types only when they solve a specific need. {% endhint %} ## Choose a model type


SQL models Use SQL files for most transformations, scheduling, and materialization patterns.	/pages/KC00uEh7BkdwGhR3HEFY
Python models Use Python when you need custom logic, external libraries, or DataFrame APIs.	/pages/zCuOpmGkw6sdDEU2UmfQ
External models Describe external table schemas so Vulcan can reason about lineage and optimization.	/pages/lYtBypYkesDLMPGa9z1I
Managed models Let the engine maintain refreshes automatically for supported managed table features.	/pages/CMFS5viXSX5anyuMJ7Rq

## Common decision points ### Choose SQL models when * the transformation is naturally expressed in SQL * you want broad engine support * you need standard Vulcan model behavior ### Choose Python models when * the logic depends on Python libraries or APIs * DataFrame code is clearer than SQL * you can define schemas and dependencies explicitly ### Choose External models when * the source table already exists outside Vulcan * you need schema metadata, not lifecycle management * you want better lineage for external dependencies ### Choose Managed models when * the engine supports managed refresh natively * you want automatic freshness without manual scheduling * the source data changes outside normal Vulcan execution ## Best practices Prefer SQL models unless Python or engine-managed behavior is clearly needed. Keep external model definitions accurate, because Vulcan relies on them as metadata contracts. Use managed models carefully in production, and confirm engine-specific limits before rollout. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://v2.dataos.info/concepts/resources/vulcan/components/model/types.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.