Turso

Turso is an edge-deployed database platform built on libSQL — an open-source fork of SQLite with extensions for network access, replication, and encryption. It enables the database-per-user or database-per-tenant architecture at scale: each user or tenant gets a fully isolated SQLite database deployed to the nearest edge location globally. The Platform API manages organizations, databases, groups, and auth tokens. The HTTP API (Hrana protocol) executes SQL queries against individual databases. Turso is ideal for multi-tenant SaaS applications, mobile offline-first apps, and edge computing use cases where low latency and data isolation are paramount.

Evaluated Mar 06, 2026 (0d ago) vcurrent
Homepage ↗ Repo ↗ Other turso sqlite libsql edge-database rest-api multi-tenant embedded serverless replication database-per-user
⚙ Agent Friendliness
68
/ 100
Can an agent use this?
🔒 Security
83
/ 100
Is it safe for agents?
⚡ Reliability
78
/ 100
Does it work consistently?

Score Breakdown

⚙ Agent Friendliness

MCP Quality
0
Documentation
82
Error Messages
72
Auth Simplicity
80
Rate Limits
75

🔒 Security

TLS Enforcement
100
Auth Strength
80
Scope Granularity
78
Dep. Hygiene
80
Secret Handling
78

Database auth tokens (JWT) per database. Platform API tokens for management. libSQL protocol over HTTPS/WebSockets. Encryption at rest. Multi-tenancy via per-database token isolation.

⚡ Reliability

Uptime/SLA
82
Version Stability
78
Breaking Changes
75
Error Recovery
78
AF Security Reliability

Best When

An agent needs to provision or query SQLite-compatible databases at the edge, especially for multi-tenant architectures where each tenant has a fully isolated database with global replication and no operational overhead.

Avoid When

You need PostgreSQL semantics, high-concurrency writes, or very large single-database workloads beyond SQLite's practical limits.

Use Cases

  • Per-user or per-tenant SQLite database provisioning for multi-tenant SaaS at scale
  • Edge-deployed databases that serve queries from the nearest PoP globally for sub-5ms latency
  • Mobile and offline-first applications using the embedded libSQL driver
  • Lightweight serverless functions with a local SQLite database at the edge (e.g., Cloudflare Workers)
  • AI agent persistent memory using SQLite as a per-agent database with full isolation
  • Rapid prototyping with SQLite compatibility — no schema migration tools required for simple schemas

Not For

  • Heavy analytical workloads requiring complex joins over billions of rows (SQLite is single-writer)
  • Applications requiring PostgreSQL-specific features: JSONB operators, arrays, partitioning, or complex stored procedures
  • High-concurrency write-heavy workloads — SQLite serializes writes; Turso's replication is eventually consistent
  • Very large single-database workloads (>10GB practical SQLite limit for performance)

Interface

REST API
Yes
GraphQL
No
gRPC
No
MCP Server
No
SDK
Yes
Webhooks
No

Authentication

Methods: api_key
OAuth: No Scopes: Yes

Two-tier auth model: (1) Platform API tokens — organization-scoped, used to manage databases, groups, and tokens; (2) Database auth tokens — database-specific JWT tokens generated via the Platform API for data-plane access. Platform tokens can create, rotate, and revoke database tokens. Database tokens support expiration (short-lived for security) and can be scoped read-only. Agents managing infrastructure need platform tokens; agents querying data need database tokens.

Pricing

Model: freemium
Free tier: Yes
Requires CC: No

Exceptionally generous free tier — 500 databases with 9GB storage makes it ideal for testing multi-tenant architectures. No credit card required. The database-per-tenant model is viable at scale on paid tiers. Data transfer fees may apply for cross-region replication on paid plans.

Agent Metadata

Pagination
cursor
Idempotent
Full
Retry Guidance
Not documented

Known Gotchas

  • Two-tier auth requires managing both platform tokens (for management) and database tokens (for queries) separately — agents often confuse which token to use for which operation
  • Database tokens must be generated via the Platform API before use — they are not auto-provisioned; agents must provision a token before they can query a newly created database
  • libSQL extends SQLite but is not 100% identical — some SQLite extensions and pragmas differ; JSON5 support and ATTACH DATABASE behavior diverge
  • No webhooks — agents must poll the Platform API for database provisioning completion (database state: ready vs provisioning)
  • Replication lag between primary and replica locations can cause read-your-writes inconsistency — use the primary URL directly for immediate consistency after writes
  • SQLite serializes all writes — high-concurrency write agents hitting the same database will queue; design around this with per-tenant isolation
  • Database group placement affects latency — databases must be assigned to a group (geographic region set) at creation; cannot be moved post-creation without recreation
  • No MCP server available — agents must use the REST APIs or SDKs directly; no natural language interface to Turso

Alternatives

Full Evaluation Report

Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Turso.

$99

Scores are editorial opinions as of 2026-03-06.

5178
Packages Evaluated
26151
Need Evaluation
173
Need Re-evaluation
Community Powered