# Platform profiles > What a platform profile records, from dialect and table format to known traps, and how the agent uses it on every request in your project. A platform profile is a structured description of one data platform. When you connect a workspace, Emolysis loads its profile, and the agent uses it on every request. That is how the agent writes Databricks code for Databricks without guessing: platform awareness is data the agent reads, not instructions hidden in a prompt. ## What a profile records Every platform uses the same fields. The field names can change before the first release. | Field | What it holds | | ------------------------ | ------------------------------------------------------ | | `platform` | The platform id: `databricks`, `snowflake` or `fabric` | | `display_name` | The platform's name as shown to you | | `profile_version` | The version of this profile | | `dialect` | The SQL dialect generated code is translated into | | `languages` | Languages the platform runs, such as SQL and Python | | `table_format` | Delta, Iceberg or the platform's native format | | `merge_idiom` | How the platform merges changes into a table | | `incremental_primitives` | The platform's tools for incremental loads | | `deployment_unit` | What a deploy produces, such as an Asset Bundle | | `compute_apis` | How work is submitted: jobs, warehouses, sessions | | `auth` | How you sign in to the platform | | `known_traps` | Mistakes that are easy to make on this platform | | `local_sampling` | How samples are read into DuckDB | ## What each platform's profile says Status: Databricks comes first. The Snowflake and Microsoft Fabric profiles are drafts, their connectors are tested only against simulated services, and none of the three platforms' connectors has run on a real account yet. | Field | Databricks | Snowflake | Microsoft Fabric | | ----------------- | -------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------ | | Dialect | Databricks SQL and PySpark | Snowflake SQL and Snowpark | Spark SQL and PySpark; T-SQL in warehouses | | Table format | Delta, governed by Unity Catalog | Native or Iceberg tables | Delta in OneLake | | Merge idiom | `MERGE INTO`, with Delta Change Data Feed where it is on | `MERGE` fed by streams; dynamic tables | `MERGE` on lakehouse Delta tables | | Incremental tools | Auto Loader; Lakeflow Declarative Pipelines | Streams and tasks; dynamic tables | Notebooks on a pipeline schedule; Dataflow Gen2 | | Deployment unit | Databricks Asset Bundle (`databricks.yml`) | SQL scripts, tasks, streams and dynamic tables | A PySpark notebook in a workspace | | Compute | Jobs, SQL warehouses | Virtual warehouses | Spark job definitions and sessions; SQL analytics endpoint | | Sign-in | OAuth, or a personal access token | Key-pair or a programmatic access token | Microsoft Entra ID | | Known traps | Serverless versus classic compute; Unity Catalog grants | Uppercase identifier folding; warehouse auto-suspend | Item definitions and creation order when deploying through the API | | Local sampling | A SQL warehouse or Unity Catalog volumes | The Snowflake connector, or a stage as Parquet | Lakehouse tables through Spark | Each platform has its own page: [Databricks](https://emolysis.com/platforms/databricks), [Snowflake](https://emolysis.com/platforms/snowflake) and [Microsoft Fabric](https://emolysis.com/platforms/microsoft-fabric). PostgreSQL is in development as a source and SQL Server is planned as one; both use the same profile format. See [Sources](https://emolysis.com/docs/sources). ## How the agent uses it - The profile is loaded as part of the agent's instructions for every request in that project. - Only templates for that platform are offered. - Lint rules for that platform run on every pipeline the agent writes, so the known traps are caught before anything runs. - Every generated file is tagged with `platform` and `profile_version`. A file written for one platform cannot be deployed to another without an explicit translation step. See [Deploying](https://emolysis.com/docs/deploying). ## Known traps, by example On Databricks, code that works on classic compute can behave differently on serverless compute, and Unity Catalog permissions decide what a job can read. On Snowflake, unquoted identifiers fold to uppercase, and warehouse auto-suspend affects schedules and cost. On Microsoft Fabric, deploying workspace items through the API needs care with item definitions and order. The profile names these so the agent and the lint rules can avoid them. This is why a profile is data rather than a prompt: a known trap is caught by the platform's lint rules on every pipeline, the same way every time. ## Versions Profiles change as platforms change. A new profile version can add traps or tools; your existing files keep the version they were written with until you update them. The `profile_version` tag on each file says which one that is. ## The same format for every platform Every platform uses the same profile fields, which is why adding a platform does not change how the rest of Emolysis works. Sources such as SQL Server and PostgreSQL use the same format. ## Related [Platform profile](https://emolysis.com/glossary/platform-profile), [Unity Catalog](https://emolysis.com/glossary/unity-catalog) and [OneLake](https://emolysis.com/glossary/onelake) in the glossary. For the connect flow on the first platform, see [Connecting Databricks](https://emolysis.com/docs/connect-databricks). --- Page: https://emolysis.com/docs/platform-profiles. Emolysis is a product of Bandpey GmbH, Munich, Germany. It is in private development, and nothing is released yet.