Neon scales idle Postgres to zero. Turso has nothing to wake.
Both are serverless, managed databases for developers who need a lot of databases. They take two different shapes, and the differences matter at certain points. If you're evaluating or switching from Neon, this page shows where each one works and how to decide.
Four things that set Turso apart
Turso and Neon are both developer-first managed databases. These are the four differences that matter most.
Nothing to wake up
Turso databases don't scale to zero. Reads still hit the local replica instantly. There is no cold start to wait on.
Unlimited databases from the free plan
The free plan gives you 500 databases. Paid plans are unlimited. Neon's limits scale with the plan.
The database goes where your data is
Embedded replication puts a read replica on any device or edge node, with sync built into the driver. Neon runs server-side only.
Take Turso, keep your stack
Turso speaks SQLite's dialect, not Postgres. If you're already using SQLite or libSQL, there is nothing to relearn.
Two managed databases, two different bets
Turso and Neon are both good choices for developers who need many databases. They are built on different engines and optimized for different application shapes.
Turso
Turso is built on libSQL, a fork of SQLite. It is designed for the many-database architecture: one database per user, agent, or tenant. Each database is lightweight, runs anywhere (server, edge, or device), and costs only storage when idle. Turso is the right choice when isolation, edge deployment, and offline sync are first-class requirements.
Neon
Neon is a serverless Postgres. It scales idle branches to zero and is a strong fit for teams that want Postgres semantics, rich extensions, and a branching workflow for development. Neon runs server-side and requires a connection to execute queries.
Worth it for teams who need full Postgres compatibility: Neon is the better starting point. Worth it for teams building with SQLite, on the edge, or per-user isolation: Turso is the better fit.
Where Turso makes the difference
Nothing to wake up
Turso
Turso databases do not scale to zero. Reads still hit the local replica instantly. There is no cold start to wait on.
Neon
Neon branches scale to zero after a period of inactivity. The first query after the idle period wakes compute, which adds latency.
Your data can sit on the device or in the cloud
Turso
Embedded replication puts a read replica on any device or edge node. Sync is built into the driver and works offline. Reads never need a round-trip to a server.
Neon
Neon runs server-side only. There is no embedded driver; every query goes over the network.
“We chose Turso because embedded replication and sync simply aren't available anywhere else.”
Simon Henriksen
CTO, Kin
Unlimited databases, any account tier
Turso
Free plan: 500 databases. Paid plans: unlimited. Each database is isolated, lightweight, and costs only storage when idle.
Neon
Neon uses a branching model: branches live within a project. Limits on branches and projects scale with the plan.
Side by side, row by row
A direct feature comparison. Run your own workload against both before deciding.
| Feature | Turso | Neon |
|---|---|---|
| Engine | libSQL (SQLite fork) | PostgreSQL |
| Architecture | Many databases, one per tenant/user | Single database, branching |
| Run on device or in the browser | Yes, embedded replication and sync | No, server-side only |
| Offline writes and sync | Yes, with libSQL embedded sync | No |
| Cold start | None, databases do not scale to zero | Yes, branches scale to zero |
| Databases per account (free) | 500 | Unlimited branches on paid plans |
| Postgres extensions | No | Yes, full extension support |
| Database replication / failover | Yes, globally distributed | Yes, within regions |
| Horizontal scale-out | Multiple databases, each isolated | Read replicas on Postgres |
| Open source | Yes (libSQL, MIT) | Yes (Neon, Apache 2) |
| SQL dialect | SQLite | PostgreSQL |
| Pricing model | Per database row + storage | Compute-seconds + storage |
Two different meters, so run your own workload through both
Turso and Neon price differently. The model that is cheaper depends on your read/write ratio and idle time.
What counts your Turso bill
Turso charges per billion rows read, per million rows written, and per GB of storage. Idle databases cost only storage. No compute clock running when nobody is connected.
What counts your Neon bill
Neon charges for compute-seconds while a branch is active, plus storage. Branches that scale to zero still accumulate storage costs. Cold starts add latency on the first request.
For a fair comparison, take your actual query volume and idle time and run it through both calculators.
Which shape is your application?
Pick the one that matches how your application is structured.
Choose Turso if:
- You build one database per user, tenant, or agent
- Your app runs on edge runtimes or mobile devices
- You want offline reads and writes with sync
- You're already using SQLite and want cloud scale
- Isolation, not shared-schema row filtering, is your model
Choose Neon if:
- You need full Postgres compatibility and extensions
- You're running a monolith or a handful of databases
- Your team already knows Postgres and wants to stay there
- You want point-in-time recovery and Postgres branching
Still not sure? Spin up both for free and run your workload.
The same question, answered by team
- Client-side apps
- TursoEmbedded sync and offline reads are first-class.
- App/agentic platform
- TursoOne database per agent, no shared state.
- Local-first web
- TursoEmbedded replication is the feature.
- Inference microservice
- EitherDepends on SQL dialect preference.
- Multi-tenant SaaS
- TursoHard isolation at the database level, not just row-level security.
- Database-per-developer tooling
- NeonBranching workflow is purpose-built for this.
Questions developers ask before they decide
- Is Turso a Postgres database?
- No. Turso is built on libSQL, a fork of SQLite. It speaks the SQLite dialect. If you need Postgres-specific features or extensions, Neon is the better fit.
- Does Turso scale to zero?
- Turso databases don't scale to zero. They stay warm. Reads hit the local replica without a wake-up penalty. You don't pay compute; you pay per row read and written.
- What happens when Neon databases go to zero?
- Neon branches scale to zero after inactivity. The first query after a cold period wakes the compute, which can add hundreds of milliseconds to response time.
- Can I run cross-database operations across thousands of Turso databases?
- Each Turso database is isolated. Cross-database queries run at the application layer. For truly shared data, keep a single shared database alongside per-tenant databases.
- How do Neon migrations work?
- Neon uses Postgres migrations via standard tools (pg_migrate, Flyway, Drizzle). Turso uses the parent schema pattern: a parent database defines the schema, child databases inherit it.
- What is cheaper?
- Depends on workload. Turso is cheaper for workloads with many idle databases and bursty writes. Neon is cheaper for workloads with sustained compute and Postgres-native queries.
Spin up a database per user in under a minute.
500 databases free. Unlimited on paid plans. No cold start.
