Databricks Blog Details How Procore Rebuilt Its Analytics Product on OpenSharing
Databricks published a case study on how construction software maker Procore replaced its API-based analytics backend with Databricks OpenSharing to lift refresh limits and double its data catalog.
ひとことで言うと
How did Procore rebuild its analytics product using Databricks OpenSharing?
Databricks said construction software maker Procore replaced an API-driven, SQL Server-based analytics backend limited to daily refreshes with Databricks OpenSharing. The new system lifts the refresh ceiling to multiple times per day, distributes hundreds of curated tables through Unity Catalog-governed shares, and doubled the catalog of data customers can extract, according to the blog post.
要点
- Databricks published a blog post describing how Procore, a construction management software provider, rebuilt its Procore Analytics product using Databricks OpenSharing instead of its original API-driven SQL Server backend.
- According to Databricks, the original system capped data refreshes at once daily, or up to three times daily for paying customers, while the OpenSharing-based version removes that ceiling so customers can pull data on an hourly basis.
- Databricks said OpenSharing now distributes hundreds of curated tables and manages hundreds of thousands of distinct per-customer data shares, governed centrally through Unity Catalog.
- The blog post states that Procore Analytics 2.0 reached a catalog of hundreds of available tables in less than half the time it took to build out Procore Analytics 1.0, doubling the surface area of extractable data.
- Databricks described a medallion architecture (bronze, silver, gold layers) running across multiple regions, with automated entitlement reconciliation that enforces per-user, per-project data access without manual provisioning.
What was announced
Databricks published a case study describing how Procore, a construction management software provider, rebuilt its customer-facing analytics product, Procore Analytics, on top of Databricks OpenSharing. The post, written by Krishan Kumar, says the rebuild replaced an API-driven backend that had capped how often customers could refresh their data.
The old system's limits
According to Databricks, the first generation of Procore Analytics ran on a SQL Server backend fed by extractions from Procore's public APIs into an Azure database. That architecture restricted customers to one data refresh per day, with a maximum of three per day available to customers who paid for additional refreshes. Databricks said the API-based extraction process was also expensive and prone to timeouts, since it required deep recursive calls across tens of thousands of customers.
The new architecture
Databricks said Procore built the new version, Procore Analytics 2.0, on a medallion architecture inside Databricks. Raw data from Procore's application database lands in a bronze layer, is cleaned and validated in a silver layer, and is aggregated and modeled in a gold layer. Processing for bronze, silver, and gold runs across multiple regions close to the source data, and gold tables are consolidated into a single primary analytics region, from which OpenSharing distributes the data to customers.
The blog post describes two ways customers receive data. Customers without a Databricks workspace generate an OpenSharing token inside the Procore application and connect through the open protocol. Customers who already run Databricks add their workspace identifier and receive shares natively through Databricks-to-Databricks sharing without the data moving.
Databricks said access is managed through a scheduled job that reads each user's permissions from the Procore application and reconciles them against OpenSharing entitlements, enforcing access per user and per project without manual setup. Sharing runs through Unity Catalog, which Databricks said allows, as one example, a general contractor to share project progress with a property owner while keeping its own financial data private. Tables are shared at the schema, view, table, and partition level, and Change Data Feed is enabled so recipients can sync only what has changed rather than full datasets.
Scale and impact
Databricks said OpenSharing now distributes hundreds of curated tables and manages hundreds of thousands of distinct data shares across Procore's customer base. The blog post states that Procore Analytics 1.0 took several years to build out its baseline catalog of tables and fields, while Procore Analytics 2.0 reached a catalog of hundreds of tables in less than half that time, effectively doubling the data customers can extract.
For refresh frequency, Databricks said the move to OpenSharing removed the once-a-day ceiling, letting customers schedule refreshes on their own cadence, with many pulling data multiple times a day. The post also describes a reorganization of Procore's data team, consolidating what had been separate pipelines for analytics and in-app reporting into a single pipeline that feeds domain teams aligned to business areas such as finance.
Source: Databricks Blog, "How Procore is powering construction analytics with OpenSharing," published October 29, 2026.
よくある質問
- What problem was Procore trying to solve with its analytics product?
- Databricks said Procore's original analytics product, built on an API-driven SQL Server backend, was limited to one data refresh per day (up to three for paying customers), which lagged behind the hourly pace of change on construction projects.
- What is OpenSharing in this context?
- Databricks described OpenSharing as the sharing protocol Procore used to distribute curated, governed data tables directly to customers' own environments, replacing recursive API calls with sharing of already-modeled data secured through Unity Catalog.
- How do customers without Databricks access the shared data?
- According to the blog post, customers without a Databricks workspace generate an OpenSharing token inside the Procore application and connect via the open protocol, while customers who already use Databricks receive shares natively through Databricks-to-Databricks sharing.
- What change management process did Procore put in place for this data product?
- Databricks said Procore adopted a release cadence of four breaking-change releases per year with six weeks of advance notice, and twelve non-breaking releases per year with three weeks of notice.