<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Using Delta Sharing to hold ISV entitlement data outside the customer's metastore — reasonable fit? in Administration &amp; Architecture</title>
    <link>https://community.databricks.com/t5/administration-architecture/using-delta-sharing-to-hold-isv-entitlement-data-outside-the/m-p/167884#M5567</link>
    <description>&lt;P&gt;We're an ISV. Our product is installed into each customer's own Databricks&lt;BR /&gt;workspace as a dedicated deployment. We maintain the code and run all&lt;BR /&gt;deployments; the customer never installs anything themselves.&lt;/P&gt;&lt;P&gt;We license per store, so the product needs to know which of the customer's&lt;BR /&gt;stores are licensed. That record has to be readable by the customer but not&lt;BR /&gt;modifiable — and since they hold admin over their own metastore, anything we&lt;BR /&gt;leave in their workspace can be changed by them.&lt;/P&gt;&lt;P&gt;Our plan is to keep the list in our own workspace; Delta Share it read-only into&lt;BR /&gt;theirs, and have our batch jobs read the share directly at decision time, so&lt;BR /&gt;nothing in the enforcement path reads a table they can write to. At job startup&lt;BR /&gt;we also check that the catalog really is a Delta Sharing catalog originating&lt;BR /&gt;from our provider, so a similarly named local catalog can't be substituted.&lt;/P&gt;&lt;P&gt;We've tested the basics — the share mounts, a local view can reference it, and&lt;BR /&gt;writes are refused at credential vending, which is the behaviour we wanted.&lt;/P&gt;&lt;P&gt;Is Delta Sharing a reasonable fit for holding per-customer entitlement data this&lt;BR /&gt;way, or are we stretching it beyond what it's meant for? Interested in how other&lt;BR /&gt;ISVs handle entitlement that the customer must be able to read but not change.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks in Advance!&lt;/P&gt;</description>
    <pubDate>Tue, 08 Sep 2026 08:29:16 GMT</pubDate>
    <dc:creator>vamsi_simbus</dc:creator>
    <dc:date>2026-09-08T08:29:16Z</dc:date>
    <item>
      <title>Using Delta Sharing to hold ISV entitlement data outside the customer's metastore — reasonable fit?</title>
      <link>https://community.databricks.com/t5/administration-architecture/using-delta-sharing-to-hold-isv-entitlement-data-outside-the/m-p/167884#M5567</link>
      <description>&lt;P&gt;We're an ISV. Our product is installed into each customer's own Databricks&lt;BR /&gt;workspace as a dedicated deployment. We maintain the code and run all&lt;BR /&gt;deployments; the customer never installs anything themselves.&lt;/P&gt;&lt;P&gt;We license per store, so the product needs to know which of the customer's&lt;BR /&gt;stores are licensed. That record has to be readable by the customer but not&lt;BR /&gt;modifiable — and since they hold admin over their own metastore, anything we&lt;BR /&gt;leave in their workspace can be changed by them.&lt;/P&gt;&lt;P&gt;Our plan is to keep the list in our own workspace; Delta Share it read-only into&lt;BR /&gt;theirs, and have our batch jobs read the share directly at decision time, so&lt;BR /&gt;nothing in the enforcement path reads a table they can write to. At job startup&lt;BR /&gt;we also check that the catalog really is a Delta Sharing catalog originating&lt;BR /&gt;from our provider, so a similarly named local catalog can't be substituted.&lt;/P&gt;&lt;P&gt;We've tested the basics — the share mounts, a local view can reference it, and&lt;BR /&gt;writes are refused at credential vending, which is the behaviour we wanted.&lt;/P&gt;&lt;P&gt;Is Delta Sharing a reasonable fit for holding per-customer entitlement data this&lt;BR /&gt;way, or are we stretching it beyond what it's meant for? Interested in how other&lt;BR /&gt;ISVs handle entitlement that the customer must be able to read but not change.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks in Advance!&lt;/P&gt;</description>
      <pubDate>Tue, 08 Sep 2026 08:29:16 GMT</pubDate>
      <guid>https://community.databricks.com/t5/administration-architecture/using-delta-sharing-to-hold-isv-entitlement-data-outside-the/m-p/167884#M5567</guid>
      <dc:creator>vamsi_simbus</dc:creator>
      <dc:date>2026-09-08T08:29:16Z</dc:date>
    </item>
    <item>
      <title>Re: Using Delta Sharing to hold ISV entitlement data outside the customer's metastore — reasonable f</title>
      <link>https://community.databricks.com/t5/administration-architecture/using-delta-sharing-to-hold-isv-entitlement-data-outside-the/m-p/167888#M5568</link>
      <description>&lt;P&gt;See this blog&lt;BR /&gt;&lt;BR /&gt;&lt;A href="https://www.databricks.com/blog/introducing-new-databricks-partner-program-and-well-architected-framework-isvs-and-data" target="_blank"&gt;https://www.databricks.com/blog/introducing-new-databricks-partner-program-and-well-architected-framework-isvs-and-data&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 08 Sep 2026 08:54:43 GMT</pubDate>
      <guid>https://community.databricks.com/t5/administration-architecture/using-delta-sharing-to-hold-isv-entitlement-data-outside-the/m-p/167888#M5568</guid>
      <dc:creator>Satyasai</dc:creator>
      <dc:date>2026-09-08T08:54:43Z</dc:date>
    </item>
  </channel>
</rss>

