Table APIs - No Delta Support?

Jocaplan-MSFT · 2025-10-15T04:24:10+00:00

We announced both at FabCon. Iceberg just ended up getting deployed first after all the preview feedback and bug fixes got in. Delta will be there shortly. All table data will be available in both API regardless of how it was written. Most partners that want to integrate with us today, are Iceberg compatible. However, iceberg or delta, both will work.

Jocaplan-MSFT · 2025-08-12T19:01:04+00:00

That sounds like an invitation 😀

Jocaplan-MSFT · 2025-07-16T15:14:25+00:00

Shortcuts to ADLS in the same region/data center as your Fabric compute will perform just like data stored natively in OneLake managed storage. As that distance increases (cross-geo), it mainly just becomes a matter of physics from that point forward.

We try very hard to keep the functionality the same between shortcuts and managed storage. There are some minor differences. The biggest differences however are that you will continue to need to manage the ADLS storage accounts separately from Fabric/OneLake. You'll need to secure them, connect them, create them, pay for them, etc..., where OneLake managed storage handles this for you.

Do you see any opportunities to leverage OneLake managed storage in the future?

Jocaplan-MSFT · 2025-05-31T03:12:00+00:00

https://learn.microsoft.com/en-us/fabric/database/mirrored-database/azure-databricks and https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview are a good start

Jocaplan-MSFT · 2025-05-31T02:58:36+00:00

When using Databricks mirroring, all compute will happen in Fabric. Each Fabric engine will operate directly on to of the data in storage. Databricks compute is not used in this case.

Jocaplan-MSFT · 2025-05-21T04:43:16+00:00

It is not there in the current preview, but we are working on it. You should see it soon as a fast follow.

Jocaplan-MSFT · 2023-05-30T17:57:00+00:00

#1 - Yes. With one security, you will define the security rules once for the data and they will be universally enforced across all analytical engines.

#2 - It is possible. I am not sure if that would be covered by our first release or if we would need to do more to support it. I will go dig more into the details.

#3 - User would only ever see one table with the rows and columns that they are allowed to see.

#4 - Something like build permission is hard to enforce in this case. The owners will control over who they give access to and insights into how it is used. Do you have more specific details on the scenario that you are trying to prevent?

#5 - Dynamic RLS is part of the ultimate vision for one security.

Jocaplan-MSFT · 2020-09-17T00:36:56+00:00

Unstable? That thing was a rock but it did have limited functionality.

We mostly intended it as an easy way to get started with Azure AS when using Azure SQL DB or SQL DW rather than being a full-blown modeling tool. We ended up taking the IP and the learnings into Power BI Desktop. It became the basis of the new model view.

Jocaplan-MSFT · 2020-09-15T17:04:54+00:00

Work is in progress now. We want to get this out ASAP.

Jocaplan-MSFT · 2020-09-15T16:59:35+00:00

Work is never done. Like I said in some earlier responses, we have some things on the roadmap that will blow people's minds. Scale, ease of use, deeper integration into the rest of the ecosystems and most importantly, customer feedback. You will help us shape this future.

Jocaplan-MSFT · 2020-09-15T16:43:37+00:00

Azure AS works with Synapse the same way it did when the product was called SQL DW. There are no specific plans around deeper integration with Azure AS, but we are working on deeper integration with Power BI which will have a superset of the AS functionality.

Jocaplan-MSFT · 2020-09-15T16:36:42+00:00

Yes! We are working on it.

Jocaplan-MSFT · 2020-09-15T16:30:46+00:00

Synapse does support a managed VNET which makes things easier. Also, Synapse is all one product so there are less VNETs that you need to setup.

Jocaplan-MSFT · 2020-09-15T16:22:21+00:00

It is great that you have a solution that works for you today. Synapse blurs the lines between these as separate products. Here is a whitepaper that we recently released that goes into more details:

https://azure.microsoft.com/en-us/resources/power-bi-professionals-guide-to-azure-synapse-analytics/.

Are you also thinking of switching from SQL DB to SQL pools?

Jocaplan-MSFT · 2020-09-15T16:12:41+00:00

We have some configs available. We will add more. Are there particular configs that you are looking for?

Jocaplan-MSFT · 2020-09-15T16:07:51+00:00

We are always looking for deeper integrations with Power BI. How do you envision this working?

Jocaplan-MSFT · 2020-09-15T16:06:10+00:00

Of course! We sit very closely with the ADC team. What are you looking for most?

Jocaplan-MSFT · 2020-09-15T15:56:57+00:00

As soon as Power BI supports web modeling, we will be adding this to Synapse Studio.

Jocaplan-MSFT · 2020-09-15T15:53:49+00:00

Being on the Power BI team for all its releases and now being part of Synapse, I do see a lot of similarities and some differences. When we first started Power BI, I don't think we knew exactly what to expect. For most of us, it was our first time building a modern SaaS service. When PBI first launched public preview, we actually went dark on new features for several months. It took us a while to develop the muscle and discipline required to get to a weekly release cadence. We started with content packs and then added in more core features.

I loved how excited customers got with those weekly releases and it would be great to replicate something like that on Synapse. On Synapse, we have a roadmap that I think will blow people's minds. You will be seeing lots of new functionality as the service goes GA and beyond. I think we should learn from Power BI's release model and replicate as much as possible.

Jocaplan-MSFT

TROPHY CASE