starter.wiki中文

Managed PostgreSQL

Neon

A managed PostgreSQL service with separated compute and storage, branching, autoscaling, and configurable scale-to-zero behavior.

Visit official site

Editorial verdict

Choose Neon when PostgreSQL compatibility, database branching, and elastic or suspendable compute align with the development workflow and workload. Prefer a conventional managed instance when stable always-on capacity and familiar infrastructure boundaries matter more.12

Best for

  • Web applications that want focused managed PostgreSQL
  • Preview and development workflows that benefit from isolated database branches
  • Variable workloads that can use autoscaling or scale-to-zero intentionally
12

Not ideal for

  • Applications that require a broader integrated backend platform by default
  • Latency-sensitive workloads that cannot tolerate compute suspension behavior
  • Teams unwilling to model compute, storage, branches, restore history, and network usage
34
Main trade-off

Neon's elastic compute and branching improve workflow flexibility, but cost and performance depend on compute activity, autoscaling limits, suspension, branches, storage, restore history, transfer, and connection patterns.134

Product boundary

Whether managed PostgreSQL with branching and elastic compute fits better than an always-on database service or a broader backend platform.

Neon manages PostgreSQL infrastructure, compute endpoints, storage, branching, and recovery features. The application still owns schema design, query performance, connection behavior, data governance, migrations, and recovery verification.12

For: Web and serverless application teams that want PostgreSQL with managed elastic compute and database branches

  • The workload must remain continuously warm with predictable instance behavior.
  • The product wants an integrated backend rather than a focused database service.
  • PostgreSQL extensions, connection modes, regions, or recovery requirements do not fit the current service.

Why teams consider Neon

  • PostgreSQL foundationApplications use managed PostgreSQL rather than a proprietary SQL abstraction.1
  • Database branchingBranches provide isolated database states for development and preview workflows.2
  • Elastic computeCompute can autoscale and eligible endpoints can suspend when inactive.34
  • Separated compute and storageCompute endpoints can be managed independently around durable storage.1

Pricing

Free and usage-based plans meter compute unit hours, storage, branches beyond included allowances, restore-history storage, and network transfer. Scale-to-zero and autoscaling limits materially affect cost.3

Evaluate

Free — $0

The current page lists monthly compute and storage allowances per project; verify all current project and feature limits before relying on the plan.3

Usage based

Launch

The current page lists $0.106 per CU-hour and $0.35 per GB-month, with other dimensions including branches, restore history, and transfer.3

Higher service tier

Scale

The current page lists $0.222 per CU-hour and $0.35 per GB-month, plus expanded operational features and separate usage dimensions.3

Primary billing dimensions
Compute activity, storage, branch usage, restore history, and transfer3
Current free allowance
The cited page lists 100 CU-hours and 0.5 GB storage per project each month3
Cost control boundary
Autoscaling limits and scale-to-zero settings change both performance and spend3
Pricing checked View official pricing

Neon vs alternatives

Supabase

Choose when
Choose it when PostgreSQL should arrive with Auth, Storage, Realtime, and integrated APIs.
Compared with Neon
The database decision becomes part of a broader backend platform.7

Traditional managed PostgreSQL

Choose when
Choose it for predictable always-on instances and established network topology.
Compared with Neon
Branching and elastic serverless behavior may require separate tooling.6

Turso

Choose when
Choose it when SQLite semantics and local or embedded application data fit better than PostgreSQL.
Compared with Neon
The data model, compatibility, and operating model are different.8

Resources and sources

Official product, architecture, and pricing

  • Why Neon
    Open
  • Neon database branching
    Open
  • Neon pricing
    Open
  • Neon scale to zero
    Open
  • Neon source repository
    Open

Related tools

Starter stacks

  1. 1
    Why Neon

    Neon · Accessed Official

  2. 2
    Neon database branching

    Neon · Accessed Official

  3. 3
    Neon pricing

    Neon · Accessed Official

  4. 4
    Neon scale to zero

    Neon · Accessed Official

  5. 5
    Neon source repository

    Neon · Accessed Official

  6. 6
    Amazon RDS for PostgreSQL

    Amazon Web Services · Accessed Official

  7. 7
    Supabase database overview

    Supabase · Accessed Official

  8. 8
    Turso introduction

    Turso · Accessed Official