In private development
Databricks comes first. It is in development, Snowflake and Microsoft Fabric are planned, and none has run on a real account yet. PostgreSQL is in development as a source, and SQL Server is planned as a source.
Platforms
Emolysis writes code for the data platform you already run, and tests it on your machine first. Development runs locally on DuckDB. Production runs on your platform, under your account, in its native deployment units.
The lineup
Deploy targets: Emolysis writes code for them and deploys to them
The first target. Writes for Delta tables and Unity Catalog and deploys as Databricks Asset Bundles.
Writes for streams, tasks and dynamic tables, with Snowflake's own identifier rules.
Writes for lakehouses in OneLake and deploys notebooks to your Fabric workspace.
Read from, never deployed to: the data lands on your production platform
Planned as a source: operational tables and change data from SQL Server, read for your pipelines.
Reads tables from PostgreSQL as a source: mirrors its catalog and samples tables into DuckDB on your machine.
Your machine: the development loop and the judge for golden tests
Platform profile
Connecting a workspace loads a platform profile. The agent reads it on every request, so platform awareness is data, not a hidden instruction.
The SQL dialect generated code is translated into, and the languages the platform runs, such as SQL and Python.
Delta, Iceberg or the platform's native tables, and the catalog that governs them.
How the platform merges changes into a table, such as MERGE INTO with a change feed.
The platform's own tools for incremental loads, such as Auto Loader, or streams and tasks.
What a deploy produces: an Asset Bundle, SQL objects or workspace items.
How work is submitted: jobs, warehouses or sessions.
How you sign in to the platform, with credentials kept in your machine's credential store.
Mistakes that are easy to make on this platform, which lint rules flag.
How a small slice of a table is read into DuckDB on your machine for the golden tests.
Principle
Why it fits
The same loop on every target platform: a profile, a template, a test on your machine and a deploy in your platform's own unit.
Profile
Emolysis writes Databricks code for Databricks, and Snowflake code for Snowflake. Connecting a workspace loads a platform profile: the dialect, table format, merge idiom, incremental tools, deployment unit, sign-in method and known traps of that platform.
Deploy
What deploys is your platform's own unit. Databricks Asset Bundles; Snowflake tables, streams, tasks and dynamic tables; Fabric notebooks. They run on your platform's compute, under your account.
Tests
Every change runs golden tests on DuckDB before it reaches your platform. A red test goes back to the template, not to production. Testing on a local sample spends no warehouse compute.
Shapes
Most production work follows ten pipeline shapes. Emolysis starts from a template written for your platform instead of writing from scratch, and only your platform's templates are offered.
Tagged
Every generated file is tagged with its platform and profile version. A Databricks pipeline is never deployed to Fabric without an explicit translation step that swaps in the right template and re-runs the golden tests.
Read next
Questions
Which platforms, in what order, and how a pipeline moves between them. More in the FAQ.
Databricks is first and in development; Snowflake and Microsoft Fabric are planned after it, and none has run on a real account yet. PostgreSQL is in development as a source and SQL Server is planned as one; Emolysis reads from sources and never deploys to them. DuckDB is the local engine on your machine for development and golden tests; it is not a production target.
A platform profile is a structured description of a data platform that the agent loads the moment you connect a workspace. It records the platform's SQL dialect and languages, its table format, how it merges changes, its incremental tools, its deployment unit, its compute options, how sign-in works, its known traps and how to sample data from it. With the profile loaded, only that platform's templates are offered.
Databricks offers a complete set of APIs for everything Emolysis needs to do end to end: sign in with OAuth, read Unity Catalog, sample Delta tables, run jobs and deploy Asset Bundles. That makes it the best place to prove the whole loop. The platform profile format is the same for every platform, so the work on Databricks carries over.
There are no dates yet. Both come after Databricks. Their platform profiles are drafted. The Snowflake and Fabric connectors are built and tested only against simulated services; neither has run on a real account. Each one is announced on the news page, together with the shapes whose templates pass their tests on that platform.
As an explicit step. Every file Emolysis generates is tagged with its platform and profile version, so a pipeline cannot be deployed to another platform by accident. The pipeline is translated into the target platform's dialect, that platform's template for the same shape is filled, and the golden tests run again on the target.
PostgreSQL is in development as a source and SQL Server is planned as one, with no dates yet. Emolysis reads from them and never deploys to them. Landing their data in bronze tables on your production platform, through the Ingest (batch), Incremental append and CDC merge shapes, is planned.
Databricks first · Nothing is released yet
Early access is by invitation, starting with data engineering teams on Databricks.