Built-On Neon
Partners building their product on Neon provision a dedicated Lakebase Postgres for every end customer, application, or agent they create. Instead of running one large shared database, these platforms treat the database as a unit of tenancy: one project per tenant, created and torn down programmatically through the Neon API, scaling to zero when idle and back up on demand.
This section extends the Built On Databricks Partner Well-Architected Framework to Neon's database-per-tenant pattern: it defines the reference architecture for a product built on Neon, and the validation path by which such a partner is recognized as a Databricks Built-On partner.
This guidance is written for partners integrating directly with the Neon platform API.
What "Built-On Neon" Means
A Built-On Neon product uses Neon as the operational database layer of the product itself — not as a system the product happens to connect to. Its defining characteristics are:
- Database-per-tenant provisioning — a dedicated Neon project (an isolated Postgres cluster with its own branches, databases, roles, and compute) is created for each customer, application, or agent, giving complete data isolation.
- Programmatic lifecycle — the product backend, not a human, drives the full lifecycle: create, configure compute and quotas, connect, branch, restore, suspend, and delete, all through the Neon API.
- Serverless economics — autoscale and scale to zero when idle, so a partner can offer a dedicated database to every tenant without paying for idle capacity. This is what makes fleets of hundreds of thousands of databases economically viable. See how Retool manages 300k+ Postgres databases on Neon.
- Per-tenant metering — because each tenant maps to a project, usage (compute, storage, data transfer) is naturally attributable for billing, plan enforcement, and telemetry.
Use Cases
This framework covers two closely related patterns that share the same provisioning model but differ in lifecycle, scale, and connection strategy.
| Use case | Description | Distinguishing characteristics |
|---|---|---|
| Neon for Agents | A dedicated Lakebase backs each AI agent, code-generation session, or generated app — for example an app-building or coding agent that gives every generated app its own Lakebase. Branches and snapshots provide fast checkpoints, rollback, and sandboxes within that database. | Very high create/delete churn, short-lived and ephemeral instances, heavy use of branching and instant restore, scale-to-zero tuned aggressively (short suspend timeout), and connections often made from serverless/edge runtimes via the Neon serverless driver (HTTP/WebSocket). |
| Neon as your platform database | A platform offers managed Lakebase as part of its own product, using Neon to provision and manage a dedicated Lakebase for each customer, application, or workload, with the Postgres offering presented under the platform’s own brand. | Longer-lived tenants, plan-tier quotas, fleet-wide schema migrations, connection pooling for steady web traffic, scale-to-zero with a longer suspend timeout to balance idle cost against cold-start latency, per-customer usage-based billing. |
Framework Structure
| Page | What it covers |
|---|---|
| Reference Architecture | The end-to-end database-per-tenant framework: provisioning, compute and autoscaling, consumption limits, connectivity and API keys, connection pooling, reading and writing data, and per-customer telemetry for the two use cases. |
| Validation | Requirements to get validated as a Built-On Neon partner in the Databricks Built-On program. |
Quick Start
- Designing your provisioning model? → Start with Provisioning & Lifecycle.
- Ready to be validated? → Review the validation requirements.
Additional Resources
- Neon platform integration overview — Neon's guide to embedding Postgres for your users
- Neon API reference — API keys, authentication, and endpoints
- Built-On Databricks Partner Program