Databricks' Private Network Gateway gives serverless compute one subnet-level path into a customer network

Before PNG, each self-hosted database, Kafka cluster or internal API needed its own private endpoint, load balancer and proxy VM. It also needed coordination between the Databricks admin, the cloud admin and the network security team ^[3]. Databricks says PNG "scales by network, not by endpoint" ^[4]. In specific_destinations mode, we'd expect adding a database to mean adding one fully qualified domain name to a list.

The second mode needs a closer read. all_traffic sends outbound traffic into your network unless it matches a narrower Private Link or service-endpoint path. Those paths keep their native route ^[8]. Databricks recommends the mode for inspecting broad egress through your own firewall ^[8]. In our view, traffic on the exempt paths never reaches that firewall through PNG, so the inspection covers less than the mode's name suggests.

Fabiano Seki, a tech lead in data engineering at Banco Bradesco, said: "we can reuse an existing workspace subnet, which makes firewall approvals easier, while still controlling exactly which destinations are reachable." ^[11] The quote appears in Databricks' own announcement.

The adoption case rests on one number from Databricks' own interviews. More than 75% of customers said their network configuration and the complexity of network changes was the main reason specific workloads stayed on classic compute ^[13]. The post does not give the number of customers interviewed or how they were chosen. The figure applies to your estate only if networking is also what keeps your own jobs on classic.

The post says supported serverless workloads can reach the private destinations you allow once the NCC is attached to workspaces ^[12]. In the text available, it does not say which workloads are supported or what PNG costs.