Question 1

Why land lakehouse data in SQL Server?

Accepted Answer

Several reasons come up. Established stored procedures, scheduled reports and business intelligence tools pointed at SQL Server represent real investment, and delivering a modelled table where they already look is often simpler than repointing them. It can also be about access, where analysts or applications have SQL Server credentials but no route to the lakehouse. Either way the modelling stays in Databricks and only the result moves.

Question 2

How do I control the destination schema?

Accepted Answer

Through the model rather than afterwards. A source can be a table or an arbitrary SQL query, and the latter is what most people use here, because a lakehouse table rarely has the shape a relational reporting schema wants. Nested STRUCT, ARRAY and MAP values are worth resolving into scalar columns in that SQL, since a destination that cannot represent nesting will often store them as strings instead.

Question 3

How is the data loaded?

Accepted Answer

Bulk table replication stages rows into a scratch table and merges into the destination, keeping the visible table consistent while a load runs. Model syncs write directly, batching inserts and issuing updates per row, with failed batches retried individually so errors attach to specific records. Tables and columns are created for you, and an incompatible type change triggers a migration rather than a silently wrong value being written.

Question 4

Can reads be incremental?

Accepted Answer

Yes, on a tracking column, with the first run reading in full and later runs resuming past the stored value. A primary key is not required, though a unique key helps the reader chunk efficiently where many rows share the same tracking value. Deletes are not observed by that mechanism, and there is no source side change data feed reader, so where the destination has to match exactly a periodic full run is the way to reconcile.

Question 5

How do I connect Databricks to Microsoft SQL Server?

Accepted Answer

Connect Databricks with a SQL warehouse hostname and a token, or an OAuth service principal, and connect SQL Server with host, port, database and credentials, adding an SSH tunnel through a bastion host if the instance is not publicly reachable. Then model the data in Databricks, map it onto the destination table, and choose whether the sync replicates tables or writes a modelled result.

Connect Databricks with Microsoft SQL Server

Connect Databricks and Microsoft SQL Server with Polytomic

Staged then merged

Reaches private instances

Model the shape you need

Trusted by businesses worldwide

Step-by-step integration guide

Connect Databricks in Polytomic

Connect Microsoft SQL Server in Polytomic

Create a sync between Databricks and Microsoft SQL Server

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect Databricks with Microsoft SQL Server?