TL;DR
Turso (SQLite at the edge) and Neon (serverless PostgreSQL) are both secure for different use cases. Neon offers Row Level Security through PostgreSQL. Turso provides embedded replicas for truly local data access. Both use TLS encryption. Choose Neon for RLS needs, Turso for edge-first architectures with local replicas.
Architecture Differences
| Feature | Turso | Neon |
|---|---|---|
| Database Engine | libSQL (SQLite fork) | PostgreSQL |
| Edge Model | Edge replicas | Serverless (single region) |
| Embedded Mode | Yes (local SQLite file) | No |
| Row Level Security | No (SQLite limitation) | Yes (PostgreSQL RLS) |
| Branching | Yes | Yes |
Security Models
Turso Security
- Token-based auth: Database tokens with expiration
- Group tokens: Access multiple databases with one token
- Read-only replicas: Data distributed to edge locations
- Embedded mode: Local SQLite file synced to cloud
- No RLS: Access control must be in application
Neon Security
- Connection strings: Password-based PostgreSQL auth
- Row Level Security: PostgreSQL RLS policies
- Branching isolation: Separate credentials per branch
- Compute separation: Isolated compute instances
- IP Allow lists: Network-level restrictions (paid)
Key Difference: Neon's PostgreSQL RLS lets you enforce access control at the database level. Turso's SQLite doesn't support RLS, so you need to implement access control in your application code.
Connection Security
| Feature | Turso | Neon |
|---|---|---|
| TLS Encryption | Yes (required) | Yes (required) |
| Connection Protocol | HTTP/WebSocket | PostgreSQL wire protocol |
| Serverless Driver | @libsql/client | @neondatabase/serverless |
| Edge Runtime Support | Yes (native) | Yes (serverless driver) |
Embedded Replica Security (Turso)
Turso's unique feature is embedded replicas, which have security implications:
- Local data: SQLite file on your server or edge worker
- Sync security: Changes sync to/from Turso cloud over TLS
- Offline access: Data available even if cloud is unreachable
- File security: Local file needs filesystem-level protection
Consideration: With embedded replicas, your data exists in multiple locations. Ensure proper file permissions and encryption at rest for local SQLite files in production environments.
Encryption
| Encryption | Turso | Neon |
|---|---|---|
| In Transit | TLS (required) | TLS (required) |
| At Rest (Cloud) | Yes | Yes |
| At Rest (Local) | SQLite encryption (separate) | N/A |
Which Should You Choose?
Choose Turso If:
You need edge-deployed data with low latency, want embedded local databases that sync to cloud, prefer SQLite simplicity, or are building offline-capable applications. Accept that RLS must be app-level.
Choose Neon If:
You need PostgreSQL features including Row Level Security, want database-enforced access control, prefer a traditional serverless database model, or are using PostgreSQL-specific tools and ORMs.
Is Turso secure without RLS?
Yes, but you're responsible for implementing access control in your application. Many applications work fine with application-level security. RLS provides an additional layer that catches bugs in your application code, which Turso doesn't offer.
Can I use Turso for multi-tenant applications?
Yes, but consider using separate databases per tenant rather than sharing tables. Turso's pricing model (per database) makes this feasible. Without RLS, this provides stronger isolation than shared tables.
Which is better for Cloudflare Workers?
Both work with Cloudflare Workers. Turso is more edge-native with its libSQL driver designed for edge runtimes. Neon's serverless driver also works well but doesn't offer the embedded replica feature.