Which Modern Cloud Database Should You Choose? Start With the Workload, Not the Feature List

This deep dive is for readers moving beyond the beginner defaults (Supabase, Firestore) from the deployment guide to choose a production database on their own. Read it before locking in how your first service stores data and what it will cost.

AI coding tools have compressed the time required to build a web application. A team can generate a frontend, connect an API, deploy it, and attach a managed database in hours or days.

The database decision can feel just as easy: pick a logo, copy a connection string, and keep building.

The consequences appear later.

A real-time listener starts generating far more reads than expected. Hundreds of serverless functions exhaust PostgreSQL connections. Adding regions for a global launch increases replication and data-transfer costs. A platform feature that accelerated the first release makes a later migration surprisingly difficult.

The right question is therefore not, “Which serverless database is the best?” It is: Which database model, billing unit, and scaling behavior fit the way this product actually reads and writes data?

The 60-second decision guide

This article is based on official documentation as of 2026-09-02. Pricing and features change frequently, so verify the details in each service's official docs before adopting anything.

These are starting points, not universal winners. Validate the choice with your own read/write patterns, security rules, latency targets, and expected bill.

There is no universally cheapest, most scalable database

Serverless databases are often described as infrastructure you do not manage and capacity you pay for only when you use it. That description is useful, but incomplete.

Providers charge for different things:

• active compute time;
• documents or rows read and written;
• request units adjusted by item size and consistency;
• minimum cluster capacity plus storage, backup, replicas, and egress; or
• a broader backend platform that includes authentication, file storage, and real-time delivery.

A more realistic model is:

Monthly data cost = base subscription or minimum compute + active compute or requests + storage and indexes + replication and backup + data transfer + platform features

“Serverless” does not automatically mean “cheapest.” Scale-to-zero and request-based billing can be excellent for idle or bursty applications. A consistently busy workload may be less expensive on provisioned capacity or a predictable cluster commitment.

Answer three questions before comparing products

1. The shape of the data

If orders, customers, permissions, and contracts need relationships and transactions, PostgreSQL is a natural starting point. If the application retrieves sessions, carts, device events, or game state through stable keys, a key-value system such as DynamoDB may fit better. If real-time synchronization and offline mobile access define the product, Firestore's client experience can be more valuable than SQL flexibility.

2. The shape of the traffic

Does the service sit idle and then spike? Is traffic steady all day? Is it read-heavy or write-heavy? Must data be read near users around the world? Two applications with the same monthly request count can have very different infrastructure needs because the timing and distribution of those requests differ.

3. What the product needs beyond a database

Authentication, object storage, real-time updates, mobile SDKs, event streams, and global replication all carry development and operating costs. Comparing only the database line item can understate the value of an integrated platform. Buying a broad platform for features you will never use can create the opposite problem.

Platform or database: distinguish the layers first

These products are often discussed together, but they live at different layers. BaaS (Backend as a Service) products such as Supabase and Firebase bundle the database with authentication, file storage, and real-time sync. Database platforms such as Neon, PlanetScale, and CockroachDB sell the database itself and keep surrounding features minimal. Edge and local-first databases such as D1 and Turso focus on processing data near the user or inside the device.

• BaaS (Supabase, Firebase): a backend bundle of database plus auth, storage, and real-time features. Strong when launch speed matters most.
• Database platforms (Neon, PlanetScale, CockroachDB): the database itself is the product. You assemble surrounding features yourself but get fine-grained control over performance and cost structure.
• Edge and local-first databases (D1, Turso): data processed near the user or on the device. Evaluate when global read latency or local-first behavior is central.

A safe default for most first web apps

Unless you have a clear reason not to, start from the default.

• A typical web app → Supabase: SQL database plus authentication, storage, and real-time features in one place.
• A mobile, real-time, or offline-first app → Firestore: client synchronization and offline usage built in.

This default matches the recommendations in the deployment guide. Leave it only when one of the following conditions applies, and then use the comparison tables in this article.

Conditions for leaving the default

• PostgreSQL compatibility with scale-to-zero → Neon
• A Cloudflare Workers-based stack where integration matters → D1
• Local-first behavior or isolated databases per user or agent → Turso
• Deep AWS integration with explicit key-based access patterns → DynamoDB
• Large-scale managed SQL operations or safe database branching → PlanetScale
• Strong multi-region transaction consistency as a business requirement → CockroachDB Cloud

A practical map of modern database choices

PostgreSQL-oriented platforms: Supabase, Neon, PlanetScale, and CockroachDB

Start here when relational data, SQL, transactions, and ORM compatibility matter. These products share some SQL foundations, but they optimize for different outcomes.

Supabase combines a full PostgreSQL database with Auth, Storage, Realtime, Edge Functions, and Row Level Security. It is attractive to teams that want to launch a complete backend without integrating several vendors. Another database may have a lower isolated compute price, but Supabase can still reduce total cost of ownership when the product uses its broader platform.

Neon separates compute from storage and provides scale-to-zero, autoscaling, and database branching. It is particularly well suited to intermittent applications, preview environments, and teams that want an isolated database for each development branch. For a continuously busy production service, however, active compute accumulates steadily, so the monthly cost should be modeled with real utilization.

PlanetScale offers PostgreSQL and Vitess-based options, with an emphasis on branching, connection management, safe operations, and scale. Vitess is especially relevant to large MySQL-compatible systems that require horizontal sharding. Because a PlanetScale branch runs on its own cluster and is billed separately, teams with many persistent environments should model branch costs carefully.

CockroachDB Cloud is designed for cases where PostgreSQL-compatible tooling, resilient distributed SQL, and strong transactions across regions create clear business value. It should not be chosen merely because “global database” sounds future-proof. Cross-region replication, transfer, and transaction latency need to be justified by an actual requirement.

Edge and local-first platforms: Cloudflare D1 and Turso

Cloudflare D1 is a SQLite-based SQL database integrated with Workers. It charges primarily by rows read, rows written, and storage rather than compute hours. Global read replicas can reduce read latency and increase read throughput for Workers applications.

That billing model also means query design becomes cost design. A query that scans a large table can be billed for many rows even if it returns one result. The right index can reduce both latency and the number of billed rows.

Turso is compelling for embedded and local execution, cloud synchronization, and database-per-user, database-per-tenant, or database-per-agent designs. It fits products where many isolated databases are more natural than one large shared cluster. A centralized, write-heavy workload still needs testing with realistic concurrency and synchronization behavior.

Document and key-value platforms: Firestore and DynamoDB

Cloud Firestore packages mobile and web SDKs, real-time listeners, offline caching, and security rules into a productive client platform. For chat, collaboration, and mobile applications, those capabilities can eliminate substantial custom synchronization work.

Its operating cost is tightly coupled to the data model. Broad queries, listener updates, reconnects, composite indexes, and security-rule evaluation can add reads. Product design should include a simple question: “How many documents and index entries does one screen read?”

Amazon DynamoDB is strong for high-scale, key-oriented workloads with known access patterns. On-demand capacity reduces capacity-planning work, while Lambda, API Gateway, AppSync, and Streams make it a natural component in AWS-native systems. Once traffic becomes stable, provisioned alternatives may deserve another cost comparison.

DynamoDB is not designed around normalizing tables first and adding joins later. Define how each API will retrieve data, then build partition keys, sort keys, and secondary indexes around those access patterns. In DynamoDB, the data model is also the performance and cost model.

A workload-based selection table

This table narrows the shortlist; it does not make the final decision. Two products both labeled “SaaS” can require different databases because of their data relationships, user geography, team skills, and existing cloud commitments.

Scalability is not a single property

“This database scales” is too vague to guide a production decision. Ask which dimension scales.

• Vertical scale: Can you move to more CPU and memory predictably?
• Elastic scale: Does compute or throughput expand and contract with demand?
• Horizontal scale: Can the system add read replicas or shards safely?
• Geographic scale: Can it serve multiple regions, and with what consistency model?
• Development scale: Can a growing team create, isolate, and remove preview databases safely?

For an early startup, development scalability may matter more than global multi-write capability. For a system coordinating inventory or payments across countries, multi-region consistency and recovery may dominate. Choose the scaling dimension the product is likely to need during the next 12–18 months, not every dimension it might conceivably need one day.

Where database bills grow unexpectedly

Indexes

Indexes improve reads but add storage and write amplification. In a system such as D1, where scanned rows affect billing, a useful index can lower both latency and cost. In DynamoDB, an unused secondary index can add storage and write consumption without delivering value.

Real-time listeners

A Firestore real-time screen may require little code, but every relevant update can deliver additional document reads to connected clients. Model fan-out: one change multiplied by the number of listeners and documents refreshed.

Preview branches

Database branching can shorten development cycles, but unused environments accumulate without lifecycle rules. Separate ephemeral pull-request branches from persistent development or staging databases, and delete them automatically when possible.

Backups and replicas

Point-in-time recovery, long backup retention, read replicas, and global replication are important production features—not free abstractions. Copies and change logs can consume more storage than the primary dataset alone suggests.

Egress and region placement

Placing functions and databases in different regions increases both latency and transfer cost. Global replicas can improve local reads, but not every record needs to exist in every region.

Run a small, instrumented proof of concept

Marketing pages and pricing calculators cannot reproduce your access patterns. Shortlist two candidates and run the same representative APIs and dataset on both.

Over a two- to four-week proof of concept, compare:

• p50, p95, and p99 latency for representative APIs;
• the first request after idle time and behavior during a sudden burst;
• documents, rows, index entries, or request units consumed per API call;
• maximum client concurrency and actual backend connections;
• cost at zero traffic, normal traffic, and peak traffic;
• projected cost at three times the expected load;
• backup, PITR, replicas, observability, and transfer costs; and
• migration effort and dependence on a proprietary SDK, cloud, or event model.

Use production-shaped queries. A benchmark consisting only of primary-key lookups cannot predict the cost of administrative search, real-time screens, analytics, or batch processing.

Practical decision rules

Choose Supabase first when requirements are evolving and the team wants SQL, Auth, Storage, and Realtime in one productive platform.

Consider Neon when the application should remain PostgreSQL-compatible but intermittent traffic, preview databases, and branching economics matter.

Use Cloudflare D1 for a lightweight, read-oriented SQL service built around Workers. Consider Turso when local execution, synchronization, or many isolated per-user or per-agent databases define the architecture.

Choose Firestore when the product experience depends on real-time and offline mobile clients. Choose DynamoDB when access patterns are explicit, traffic can spike dramatically, and the application is deeply integrated with AWS.

Evaluate PlanetScale for managed SQL operations, safe branching, and Vitess-based horizontal scale. Evaluate CockroachDB Cloud when strong multi-region transactions are a business requirement rather than a speculative future feature.

Conclusion: choosing a database means choosing a cost model

Most modern managed databases are excellent. The challenge is not finding a good product; it is finding the one whose tradeoffs fit your product.

Supabase's integrated developer experience, Neon's elastic PostgreSQL, D1's Workers integration, Turso's local and database-per-entity model, Firestore's real-time clients, DynamoDB's key-based scale, PlanetScale's operational workflow, and CockroachDB's distributed transactions solve different problems.

When a team selects a database, it also selects a billing unit, scaling mechanism, consistency model, development workflow, and future migration cost. Draw the access patterns and traffic shape before comparing feature matrices. Then test real queries and measure both cost and p95/p99 latency.

The best database is not the one that wins a generic benchmark. It is the one your current team can ship with, whose costs and operations remain explainable as the product grows, and whose constraints still leave a credible path to the next stage.

Frequently asked questions

Should a new web app use SQL or NoSQL?

Start from the data relationships and queries. Accounts, teams, orders, subscriptions, and reporting usually fit SQL well. Real-time mobile state, offline clients, or clearly defined key-based access can make a document or key-value database a better fit.

Is Supabase a database or a backend platform?

Supabase is a backend platform built around PostgreSQL. The bundled Auth, Storage, Realtime, and functions can reduce setup work, but they also mean a comparison with a database-only service must include the surrounding platform.

When is a serverless database cheaper?

It can be economical when traffic is intermittent and the service can reduce idle compute. Costs can still grow through reads, writes, indexes, replicas, real-time listeners, storage, and data transfer, so model the billing units that match the workload.

Should a small product design for multi-region scale immediately?

Usually not. Treat multi-region transactions as a current business requirement only when users, contracts, latency, or availability targets demand them. Speculative scale adds cost and operational complexity before it adds value.

This article reflects publicly available information as of September 2026. Pricing, limits, and product capabilities can change; verify them in each service's official documentation before adoption.

References

• Supabase Database
• Supabase Branching
• Neon: Why Neon?
• Neon: Cost Optimization
• Cloudflare D1 Pricing
• Cloudflare D1 Limits
• Turso SDK Overview
• Cloud Firestore Pricing
• Amazon DynamoDB
• PlanetScale: Postgres vs. Vitess
• PlanetScale Postgres Pricing
• CockroachDB Cloud Costs

Next steps

• Back to the deployment guide
• The other deep dive: AI Gateways vs. Local LLM Runtimes
• CS Map System Design Part 3 — the city plan behind every real app
• The Database Guide — the 12-part database basics series for non-developers (plus an appendix)
• Beyond Vibe Coding Stage 0 — checking your starting point as a developer