Skip to main content

Built-On Neon — Validation

Built-On Neon validation certifies that your product is built on the Neon platform and that its architecture meets the Built-On Neon framework.

Design your product against the Built-On Neon reference architecture first, then use this page to prepare for validation.

Process​

PhaseWhat happens
Pre-approvalNomination-only. Please contact your Databricks Partner Manager for details.
DevelopBuild your product following the Built-On Neon reference architecture
SubmitSubmit your Partner Well-Architected Review application. Use your Databricks Partner Portal credentials to log in.
ValidationThe Databricks Partner Engineering team reviews your architecture
GTM OnboardingOnce validated, the Partner Operations team works with you on go-to-market assets

Requirements​

To be validated, your product must meet the following requirements and you must submit the assets listed below.

Architecture Requirements​

  • Built on Neon — Neon is the operational database layer of your product.
  • Project-per-tenant isolation — one project per tenant, with per-tenant roles and connection strings. Unrelated tenants are not multiplexed into a shared database. See the project is the unit of tenancy.
  • Automated lifecycle — provisioning, compute and quota configuration, connection retrieval, suspension, restore, and deletion are driven through the Neon API, not by manual action. See automate the entire lifecycle.
  • Separation of control plane and data plane — management uses Neon API keys held server-side (organization keys for the fleet, project-scoped keys for least-privilege access); applications connect over Postgres connection strings scoped per tenant. Credentials are never exposed to the browser or the tenant. See Connectivity & Data Access.
  • Secure credential handling — API keys and connection strings live in a managed secret store, are scoped and rotated, and are never committed to source or client code.
  • Compute and consumption controls — projects are provisioned with an appropriate autoscaling and scale-to-zero configuration and consumption quotas that enforce plan tiers and guard against runaway usage.
  • Connection pooling — the application request path uses pooled connections, with direct connections reserved for migrations and replication.

Metering Requirements​

Per-tenant Neon usage must be measurable and attributable to your account.

  • Minimum requirement — track the total number of projects (Postgres clusters). Because every end customer, application, or agent is allocated a dedicated project, this is the primary proxy for customer/tenant acquisition.
  • Recommended, for partners using advanced capabilities — also track the number of databases, branches, and snapshots, and per-tenant consumption (compute unit-seconds, storage, data transfer) from the consumption history API.
  • Attribution — usage must be attributable per tenant and linkable to your organization.

See Telemetry & Metering for how to collect these signals.

Required Assets for Validation​

  • Reference architecture diagram — showing the elements listed below.
  • Recorded product demo — a walkthrough of your product that shows tenant provisioning and the customer experience.
  • Neon organization details — the Neon organization(s) under which tenant projects are provisioned, so the Partner Engineering team can verify the database-per-tenant model and per-tenant metering.

Your Architecture Diagram Should Clearly Show​

  • Provisioning model — how a new tenant project is created, and the credential used (organization API key).
  • Tenancy and isolation — one project per tenant, per-tenant roles, and how connection strings are scoped and stored.
  • Compute and quotas — autoscaling/scale-to-zero configuration and the consumption quotas mapped to your plan tiers.
  • Connectivity — the separation of control-plane (API key) and data-plane (Postgres connection string) access, and where connection pooling is applied.
  • Data access — the drivers, serverless driver, or Data API your application uses to read and write, and how schema migrations are applied across the fleet.
  • Metering — how you count projects (and, if applicable, databases, branches, and snapshots) and collect per-tenant consumption.
  • Use case — whether this validation covers Neon for Agents, Neon as your platform database, or both.

Validated partners are subject to revalidation as needed when Databricks updates its validation requirements, and must comply on an ongoing basis with the Databricks Partner Program Terms and the Databricks Acceptable Use Policy.

Resources​