> Full Neon documentation index: https://neon.com/docs/llms.txt > IMPORTANT: If this page contains inaccurate or outdated information, report it: POST to https://neon.com/api/docs-feedback with {"feedback": "describe the issue", "path": "/docs/introduction/neon-and-lakebase"} # Neon vs Lakebase Two products, one architectural foundation — how to choose In 2025, Neon joined Databricks. Neon continues as a standalone serverless Postgres platform, but the same architectural foundation now also powers Databricks Lakebase, a managed Postgres product that runs natively in the Databricks Data Intelligence Platform. This section explains the [lakebase category](https://www.databricks.com/blog/what-is-a-lakebase) and how to determine whether Neon or Lakebase is a better fit for your workload. ### Lakebase architecture: Postgres built on object storage A lakebase is a new category of operational database: OLTP built directly on cloud object storage, the same storage layer already used by your lakehouse. Durability and history live in the object store, not on servers. This decouples storage from compute, making compute stateless and elastic. Operational data becomes lake-native by default, accessible to analytics and AI without ETL. Databricks is pioneering the category with [Lakebase](https://www.databricks.com/product/lakebase), a managed serverless Postgres service built on the same architectural foundation as Neon and deeply integrated into the Databricks Data Intelligence Platform. This integration unlocks capabilities that only make sense when an operational database lives alongside analytical data: - **No ETL friction.** Operational data is already in the lakehouse storage layer, so analytics, dashboards, and ML pipelines can access it without replication, CDC jobs, or fragile sync workflows. - **Unified analytics and AI.** Operational and analytical workloads work on the same data foundation. - **Lakehouse-native governance.** Access control, lineage, and security policies apply consistently across operational and analytical data through Unity Catalog. - **Serverless operations.** Like Neon, Lakebase removes manual capacity planning by using stateless compute that scales automatically and is optimized for Databricks environments. ### How to choose between Neon and Lakebase Neon and Lakebase share the same core architectural principles, but they are optimized for different environments and team structures: - Neon is Postgres for developers, startups, and agent platforms. - Lakebase is Postgres for businesses whose operational data benefits from participating directly in the Databricks Lakehouse, alongside analytics, governance, and AI workflows. **Choose Neon if:** - You're a developer looking for a hands-off Postgres to power side projects, experiments, or personal apps without setup friction or infrastructure management - You're a young startup focused on shipping quickly and need a database that keeps up without slowing your team down - You're a small team iterating fast, looking for ways to accelerate the software lifecycle and deploy safely without blockers - You're building an agent-driven or codegen platform (like Replit, Lovable, or Bolt) and need to spin up and manage fleets of databases efficiently, with costs that stay under control through usage-based pricing and scale-to-zero **Choose Lakebase if:** - You're building on the Databricks Data Intelligence Platform - You're running data-intensive or AI-driven applications where unified governance, lineage, and access control across OLTP and analytical data are essential - You're a data or AI team that needs operational data to be immediately available for analytics, notebooks, and ML workflows - You're an enterprise team that highly values security, compliance, and platform-level integrations | Product | Neon | Lakebase | | ------------------------------ | ------------------------------------------------------ | ---------------------------------------------------------------------- | | **Architecture** | lakebase | lakebase | | **What it is** | Serverless Postgres for applications | Postgres for the Lakehouse | | **Who is it for** | Developers, startups, agentic & codegen platforms | Enterprises, data & AI teams, companies building on Databricks | | **Where it runs** | Standalone serverless Postgres platform | Native to the Databricks Data Intelligence Platform | | **How teams use it** | Build, iterate, preview, and deploy apps quickly | Operate OLTP data alongside analytics and AI pipelines | | **Development workflows** | Branching, previews, instant restores, rapid iteration | Branching-based workflows integrated with notebooks and pipelines | | **Data access model** | Application-centric (ORMs, drivers, APIs) | Lakehouse-centric (SQL, notebooks, AI tooling, pipelines) | | **Operational model** | Developer-first | Enterprise-grade | | **Scaling behavior** | Autoscaling and scale-to-zero | Autoscaling and scale-to-zero aligned with Databricks serverless model | | **Governance & security** | Project-level access controls | Lakehouse-wide governance via Unity Catalog | | **Analytics & AI integration** | Via external tools and pipelines | Native integration with Databricks analytics and AI | | **Best fit when** | You're building and shipping applications quickly | You want OLTP data to participate directly in the Lakehouse | **Tip: Keep exploring Lakebase** See the [Lakebase docs](https://docs.databricks.com/aws/en/oltp), review the [latest updates to the Lakebase platform](https://www.databricks.com/blog/lakebase-holiday-update), explore [customer stories](https://www.databricks.com/product/lakebase#customer-stories), and [watch a demo](https://www.databricks.com/resources/demos/tours/appdev/databricks-lakebase?itm_data=demo_center).