What Is Serverless PostgreSQL?

What is Serverless Postgres? | Databricks Blog

Skip to main content

Serverless PostgreSQL decouples compute and storage so each scales independently, eliminating manual provisioning and charging only for active usage rather than idle capacity.

Cold start latency, connection management and variable pricing make serverless Postgres a strong fit for bursty or unpredictable workloads — but a poor fit for always-on, latency-sensitive applications.

Lakebase architecture builds on serverless Postgres to unify transactional and analytical workloads on a single platform, reducing data duplication and simplifying access for AI and real-time applications.

Serverless PostgreSQL (Postgres) is a fully managed cloud database model that decouples compute and storage. This allows each to scale independently and automatically based on demand. Instead of managing database servers directly, applications interact with systems that automatically provision compute resources in response to workload and scale them down when idle.

In traditional Postgres environments, by contrast, teams must size infrastructure in advance, estimate capacity requirements and manage scaling over time. This often results in overprovisioning, idle-cost waste and performance bottlenecks when demand exceeds available capacity.

Serverless Postgres removes much of that overhead by:

Eliminating server provisioning and infrastructure management

Removing the need for manual capacity planning

Charging only for active usage rather than idle compute

The term “serverless” can be misleading, as it does not mean applications run without servers or infrastructure. The underlying systems still exist, but they are abstracted away and fully managed by the cloud provider. Tasks like server setup, scaling and maintenance are largely invisible to users and do not need to be configured or maintained directly.

Traditional vs. serverless PostgreSQL

PostgreSQL architectures have evolved over time, moving from provisioned infrastructure models to more dynamic, cloud-native designs.

Traditional Postgres deployments run fixed compute resources continuously regardless of workload. Scaling requires manual intervention or preconfigured thresholds, with always-on costs incurred even when a database is idle.

Serverless Postgres introduced a different model. Compute resources provision on demand, scaling automatically with workload activity and scaling down to zero when not in use. Billing is based on actual consumption rather than reserved capacity.

Serverless Postgres can also be used alongside serverless compute platforms such as Databricks SQL, allowing analytical queries to run independently while still accessing the same underlying data within a unified lakehouse architecture.

This shift is enabled by architectural changes such as decoupled storage layers and on-demand compute orchestration, which allow resources to scale independently and respond dynamically to workload activity.

The key differences include:

FeatureTraditional PostgresServerless Postgres

ProvisioningManual infrastructure setupFully managed by provider

ScalingManual or preconfiguredAutomatic and on-demand

Cost modelFixed or reserved capacityUsage-based billing

Compute behaviorAlways runningSpins up per request, scales to zero

Operational overheadHigh (maintenance, tuning)Reduced (managed service)

The next evolution: lakebase architecture

As database architectures evolve, a third model is emerging that builds on serverless Postgres while addressing its limitations. This approach is sometimes referred to as lakebase architecture.

Serverless Postgres improves scalability and reduces operational overhead, but it typically remains separate from analytical systems. This separation often requires data movement, duplication or synchronization between operational databases and analytics platforms.

Lakebase architectures are changing the way we think about data storage and processing. They combine the power of transactional databases with the flexibility of a lakehouse foundation, creating a single platform where both operational and analytical workloads can run together. This means that instead of having separate systems for different tasks, everything can be done on one shared data platform. The result is less duplicated data and a much simpler way of accessing and using data. By bringing everything together, lakebase architectures make it easier to manage and analyze data, which can lead to better decision-making and more efficient operations.

How lakebase architecture works

Lakebase architectures build on serverless Postgres patterns while introducing tighter integration with cloud storage and data platforms.

Key components include:

Decoupled compute and storage Compute is stateless and scales independently, while storage remains persistent and distributed.

Ephemeral compute Compute resources spin up to process queries and scale down when idle, enabling elasticity without maintaining always-on infrastructure.

Log-based storage systems Data changes are captured as a continuous log, which can be used to reconstruct database state and support features such as branching, recovery and time-based access.

Object storage as the foundation Durable data is stored in cloud object storage, enabling scalability, durability and alignment with lakehouse architectures.

Control plane and orchestration A control layer manages scaling, routing and lifecycle events, coordinating compute and storage dynamically.

Why this matters

By combining transactional and analytical capabilities on a shared foundation, lakebase architectures can:

Reduce or eliminate data duplication between systems

Enable near real-time analytics on operational data

Simplify data architecture by consolidating infrastructure

Support emerging workloads, including AI applications that require both transactional and analytical access

This shift reflects a move from optimizing individual systems to unifying them within a single data architecture.

How serverless Postgres architecture works

Serverless Postgres is built on a cloud-native architecture that separates compute and storage into independent layers. This foundational design principle improves efficiency and flexibility by allowing each component to scale independently.

A key feature of this architecture is scale-to-zero behavior. When no queries are running, the system automatically suspends compute resources. When a new query is issued, compute is reactivated. This introduces a short delay known as cold start latency, which can range from milliseconds to several seconds depending on the provider and configuration.

Another important capability is database branching, often implemented using copy-on-write techniques. Branching allows teams to create isolated database environments for development, testing or staging without duplicating data. Changes made in a branch do not affect the original database, enabling faster iteration and safer experimentation.

Major serverless Postgres providers

Serverless Postgres offerings reflect different stages in the evolution from provisioned databases to fully cloud-native architectures. Earlier managed services introduced automatic scaling within existing database architectures. More recent cloud-native designs are built to support AI agents, real-time applications and modern operational workloads. These systems fully decouple compute and storage and introduce capabilities that are difficult to achieve in earlier models, such as rapid scaling, branching and more flexible resource management. Neon and Databricks Lakebase are built on this foundation, designed for the demands of AI-forward applications and agent-based systems.

Databricks Lakebase An operational database built on lakebase architecture that extends serverless Postgres by integrating transactional databases with a lakehouse foundation. Designed for the demands of AI agents, real-time applications and modern operational workloads, Databricks Lakebase allows operational and analytical workloads to share a common data platform. Use cases include storing AI agent state, powering transactional applications and delivering analytical insights directly into apps and workflows. The result is less data movement and more consistent access across use cases.

Amazon Aurora Serverless v2 A Postgres-compatible managed service within AWS that provides fine-grained autoscaling without requiring database restarts. Aurora Serverless v2 is designed for enterprise workloads and integrates closely with AWS services for networking, security and monitoring. While it reduces operational overhead, scaling behavior and resource isolation may still reflect underlying infrastructure constraints.

Neon A lakebase architecture built on a fully decoupled compute and storage model with log-based storage. Neon supports scale-to-zero behavior and database branching, enabling fast environment creation and more dynamic development workflows.

For analytics and data processing workloads, serverless compute is also available in platforms such as Databricks SQL. While not a transactional (OLTP) database, these systems provide serverless query execution for analytics and can operate alongside Postgres-based systems.

Open-source roots and cloud-native options

Postgres is a widely used, open-source relational database system. Serverless Postgres offerings are built on top of this foundation and retain full compatibility with the broader Postgres ecosystem, which includes extensions, command-line tools such as psql, common ORMs and more.

Implementations differ in how much of the underlying system is open versus proprietary. Some providers, such as Neon, are built on open-source infrastructure and expose more of their architecture to the community. Others, such as Amazon Aurora Serverless, are proprietary managed services that abstract much of the underlying implementation.

Regardless of approach, most serverless Postgres solutions aim to maintain full Postgres compatibility while adding cloud-native capabilities like automatic scaling, database branching and managed operations.

These differences can influence how much visibility and control teams have over performance and cost. Open-source-based systems may offer greater transparency and flexibility, while proprietary managed services often prioritize ease of use and operational simplicity.

Read now

Pricing models and performance tradeoffs

When evaluating serverless Postgres for production workloads, it is important to understand how pricing models and performance characteristics influence cost, latency and overall system behavior.

Usage-based pricing: what you're actually paying for

Most serverless Postgres providers charge across three primary dimensions:

Compute: Typically measured based on resources used during query execution, such as vCPU time or ACU seconds

Storage: Billed based on the amount of data stored, usually in GB per month

Data transfer: Charges for data moving in and out of the database, depending on region and network configuration

Because compute is provisioned on demand, costs scale with workload activity. This makes serverless pricing well-suited to applications with variable or unpredictable traffic.

Many providers offer free tiers that are useful for development, testing and small-scale workloads. These tiers typically include limits on compute usage, storage or active runtime, which makes them less suitable for production workloads or applications with sustained traffic.

While serverless pricing can be efficient for variable workloads, it is not always the lowest-cost option. In cases with high-traffic, always-on workloads or long-running queries, total costs may exceed those of a provisioned database instance with fixed capacity.

Cold starts, scaling and production reliability

One of the primary performance considerations in serverless Postgres is cold start latency. When a database has scaled down to zero, compute must be reactivated before queries can run. This introduces a delay that can range from around 100 milliseconds to several seconds depending on the provider and configuration.

Several mitigation options can reduce the impact of cold starts:

Sending periodic “keep-alive” pings to prevent full suspension

Configuring a minimum compute floor to keep resources partially active

Choosing providers that minimize or eliminate cold starts through architectural design

Serverless systems also rely on automatic scaling to handle changing workloads. Compute resources can scale up in response to increased query volume and, in some cases, scale read replicas independently to support concurrent access. This elasticity is particularly useful for applications with unpredictable traffic spikes.

For production workloads, availability and fault tolerance are critical considerations. Most managed serverless Postgres providers replicate data across multiple availability zones and offer built-in backup and recovery features. However, service-level guarantees and recovery behavior vary by provider, so it’s important to review and verify SLA coverage before production use.

Features such as cold start behavior and autoscaling make serverless Postgres well-suited to workloads with variable traffic, but can introduce tradeoffs for latency-sensitive or always-on applications.

Serverless Postgres use cases and limitations

Serverless Postgres and lakebase architecture serve different workload needs. Understanding which model fits your use case can help avoid unnecessary complexity and cost.

The following guidelines can help determine whether serverless Postgres or lakebase architecture is the right fit for your workload.

Good fit for Serverless Postgres

Most OLTP workloads

Better fit for lakebase architecture:

AI agent development and deployment

Variable or bursty workloads

Development, testing and staging environments

Startups optimizing for cost and reduced operational overhead

Serverless or edge-based applications

CI/CD workflows with rapid environment creation

Multi-tenant SaaS applications (branching and autoscaling)

For workloads that require more consistent performance or always-on availability, lakebase architecture addresses these needs by rethinking how compute and storage are coordinated on a shared data platform.

How to get started with serverless Postgres

Getting started with serverless Postgres typically involves a straightforward setup process:

Choose a provider based on your workload requirements, scaling behavior and ecosystem preferences

Create a database instance through the provider’s console or API

Configure a connection string with credentials, region and access settings

Connect using a standard Postgres client, ORM or the psql command-line tool

While setup is relatively simple, early choices can have a profound impact on overall performance and durability. First-deployment considerations should include:

Setting a minimum compute level if cold start latency is a concern

Configuring a connection pooler to manage concurrent connections in serverless or edge environments

Enabling backups and point-in-time recovery to protect against data loss

Review scaling and timeout settings to ensure they align with expected traffic patterns

Serverless Postgres can be used alongside serverless compute platforms such as Databricks SQL for analytics and data engineering. This separation allows analytical queries to run independently from transactional processing while still operating on the same underlying data.

For teams managing operational data alongside analytics, emerging architectures such as Databricks Lakebase extend this approach by unifying transactional and analytical workloads on a shared data platform. This reduces data movement and simplifies how data is accessed across systems.

Is lakebase architecture the right serverless Postgres for you?

Serverless Postgres simplifies database operations by removing much of the infrastructure management and aligning cost more closely with actual usage. Because compute and storage are decoupled, resources adjust to demand. For teams with more demanding workloads, lakebase architecture extends this foundation further.

These tradeoffs are important to evaluate carefully. Performance predictability, cost at scale and factors such as cold start latency and connection management vary by workload.

Provider choice is critical. Differences in cold start behavior, pricing models, scaling granularity and ecosystem fit can significantly impact outcomes. For analytics and data engineering workloads, platforms such as Databricks SQL provide serverless query execution. Teams can also explore how this model extends to operational workloads through the Databricks Lakebase product tour.

As database architectures continue to evolve, lakebase architecture unifies operational and analytical workloads on a shared data foundation.

Get the latest posts in your inbox

Subscribe to our blog and get the latest posts delivered to your inbox.

Sign up

View all blogs