DB9 vs Turso

DB9 and Turso are both serverless databases designed for modern applications, but they are built on fundamentally different foundations. db9 database is PostgreSQL-compatible, backed by TiKV. Turso is built on libSQL, a fork of SQLite, with per-database file storage and edge replication.

This is not just a feature comparison — it is a SQL dialect decision. Choosing between PostgreSQL and SQLite/libSQL affects your schema design, query patterns, ORM compatibility, and migration path. This page helps you evaluate both platforms honestly.

At a Glance

Capability	DB9	Turso
SQL dialect	PostgreSQL-compatible	SQLite/libSQL
Wire protocol	pgwire v3	HTTP/WebSocket (libSQL protocol)
Storage engine	TiKV (distributed KV)	SQLite B-tree (per-database file)
Provisioning	Synchronous, under 1 second	Instant (no specific SLA)
Edge replication	No	Yes (multi-region groups)
Embedded replicas	No	Yes (local SQLite file sync)
Vector search	Yes (pgvector built-in, HNSW)	Yes (native, no extension)
Native embeddings	Yes (built-in `embedding()` function)	No
Full-text search	Yes (English, Chinese/jieba, ngram tokenizers)	Yes (Tantivy-powered)
HTTP from SQL	Yes (built-in `http` — 6 methods)	No
File system in SQL	Yes (built-in `fs9` extension)	No
FUSE filesystem mount	Yes (`db9 fs mount`)	No
Document chunking	Yes (built-in `CHUNK_TEXT()` for RAG)	No
Parquet import	Yes (built-in `read_parquet()` + COPY)	No
Agent onboarding	Yes (`db9 onboard` for Claude, Codex, etc.)	AgentFS (sandbox + COW overlays)
Anonymous access	Yes (no signup, up to 5 databases)	No (account required)
Free tier	Yes (no signup, 5 databases)	Yes (100 databases, 5 GB)
SDKs	TypeScript, Browser	10 languages
Concurrent writes	Yes	Yes (libSQL multi-writer)
Extension ecosystem	9 built-in PostgreSQL extensions	SQLite extensions (different ecosystem)
ORM compatibility	PostgreSQL ORMs (Prisma, Drizzle, SQLAlchemy, etc.)	SQLite ORMs and Drizzle (libSQL driver)
CLI observability	Yes (`db9 db inspect` — queries, slow-queries, schemas, indexes)	No
Row-level security	Yes	No (application-level auth)

When to Choose DB9

You need PostgreSQL compatibility. DB9 speaks pgwire v3 and works with the entire PostgreSQL ecosystem — Prisma, Drizzle, SQLAlchemy, TypeORM, Sequelize, Knex, GORM, and any PostgreSQL driver. If your application already uses PostgreSQL, or you need PostgreSQL-specific features like row-level security, jsonb operators, CTEs with writeable expressions, or window functions, DB9 is a direct fit. Turso uses SQLite SQL, which has a different type system, different ALTER TABLE behavior, and different ORM driver requirements.

AI agent workflows. db9 database is designed for AI agents. The db9 onboard CLI installs skills for Claude Code, OpenAI Codex, Opencode, and other agents. Anonymous accounts let agents create databases without signup flows. Built-in embedding() generates vector embeddings from text directly in SQL — no external embedding API needed. Turso offers AgentFS with sandbox environments and copy-on-write overlays, but does not include native embedding generation.

Application-layer extensions. DB9 includes extensions that run application logic inside the database:

http — make HTTP requests from SQL (GET, POST, PUT, DELETE, PATCH, HEAD)
fs9 — read and write files from SQL, query file contents as tables; FUSE mount for local filesystem access
embedding() — generate text embeddings natively (default model: text-embedding-v4, 1024 dimensions)
CHUNK_TEXT() — split documents into overlapping chunks for RAG pipelines
read_parquet() — import Parquet files directly in SQL
pg_cron — schedule recurring SQL jobs
Full-text search with Chinese tokenizer support (jieba/zhparser)

These are compiled into DB9 and available without installation. Turso does not offer equivalent HTTP-from-SQL, file system access, native embedding generation, document chunking, or Parquet import capabilities.

No-signup developer experience. Developers can install the CLI and create a database without creating an account. Anonymous accounts support up to 5 databases and can be upgraded later with db9 claim. This reduces friction for prototyping, tutorials, and agent-driven workflows.

Instant provisioning with guarantees. DB9 creates databases synchronously in under a second with a deterministic SLA. The SDK’s instantDatabase() creates and returns a ready-to-use connection in a single call. This makes database-per-user, database-per-agent, and database-per-CI-run patterns practical without orchestration.

When to Choose Turso

Edge-first, latency-sensitive workloads. Turso replicates databases to edge locations using multi-region groups. Reads are served from the nearest replica. If your application runs globally and read latency is critical, Turso’s edge replication reduces round-trips to the database. DB9 does not replicate to edge locations.

Embedded replicas for offline or local-first apps. Turso syncs a full SQLite replica to the application process as a local file. Reads hit the local file with zero network latency. Writes sync back to the primary. This is powerful for mobile apps, desktop apps, and CLI tools that need to work offline or with intermittent connectivity. DB9 does not support embedded replicas.

SQLite simplicity. If your application already uses SQLite, or you want the simplicity of SQLite’s type system and file-based model, Turso extends that foundation with server-side features. SQLite’s single-file mental model, zero-configuration local development, and broad language support make it a natural fit for lightweight applications.

Broad SDK coverage. Turso provides official SDKs in 10 languages including TypeScript, Python, Go, Rust, Java, PHP, Ruby, Swift, Kotlin, and .NET. DB9 provides TypeScript and Browser SDKs. For non-TypeScript backends, DB9 works through standard PostgreSQL drivers, but Turso offers purpose-built libSQL clients with features like embedded replicas built in.

High database count on free tier. Turso’s free tier includes 100 databases and 5 GB of storage. DB9’s free tier provides 5 databases without signup. If you need many lightweight databases for free, Turso offers a higher ceiling.

Architecture Differences

Storage

DB9 uses TiKV, a distributed key-value store, as its storage engine. Each database gets an isolated TiKV keyspace. This architecture enables instant provisioning (creating a keyspace is fast) and supports PostgreSQL-compatible transaction semantics with REPEATABLE READ isolation.

Turso stores each database as a SQLite file using SQLite’s B-tree storage format. The primary database lives in one region, and replicas are full copies of the SQLite file synced to edge locations. libSQL extends SQLite with server-side write-ahead log (WAL) replication for multi-region consistency.

Compute

DB9 runs a custom SQL engine that parses, optimizes, and executes PostgreSQL-compatible queries against TiKV. Each database has dedicated compute that is always running.

Turso runs libSQL (a fork of SQLite) with extensions for server-side operation. Compute is co-located with the SQLite file at each replica location. The libSQL engine handles both local reads and forwarded writes to the primary.

Replication

DB9 does not replicate databases across regions. All reads and writes go to the same location.

Turso replicates databases across configurable region groups. Reads are served locally from the nearest replica. Writes are forwarded to the primary region and then propagated to replicas. Embedded replicas extend this model to the application process itself, syncing a local SQLite file.

SQL Dialect Differences

This is the most significant technical difference between the two platforms. DB9 and Turso use different SQL dialects, which affects schema design, queries, and tooling.

Type System

DB9 (PostgreSQL): Rich type system with integer, bigint, numeric, text, varchar(n), boolean, timestamp, timestamptz, jsonb, uuid, bytea, arrays, composite types, and more. Strict type checking at insert time.

Turso (SQLite): Dynamic type system with type affinities — INTEGER, REAL, TEXT, BLOB, NUMERIC. Any column can store any type. Type enforcement is application-side or via STRICT tables (libSQL extension).

Schema Changes

DB9 (PostgreSQL): Full ALTER TABLE support — add/drop/rename columns, change types, add/drop constraints, rename tables, all within transactions.

Turso (SQLite): Limited ALTER TABLE — add columns and rename columns/tables. Dropping columns requires SQLite 3.35.0+. Changing column types or adding constraints to existing columns requires creating a new table, copying data, and renaming.

Queries

DB9 (PostgreSQL): Supports CTEs (WITH), window functions (ROW_NUMBER(), RANK(), LAG()), LATERAL joins, jsonb operators (->, ->>, @>, ?), RETURNING clauses, upsert with ON CONFLICT, and GENERATE_SERIES().

Turso (SQLite): Supports CTEs and window functions. Does not support LATERAL joins. JSON functions use json_extract() instead of operator syntax. Supports upsert with ON CONFLICT. RETURNING is available in newer SQLite/libSQL versions.

ORM Compatibility

DB9 works with PostgreSQL-native ORMs: Prisma (postgresql provider), Drizzle (pg driver), SQLAlchemy (postgresql dialect), TypeORM, Sequelize, Knex, and GORM.

Turso works with SQLite-compatible ORMs: Prisma (sqlite provider + libSQL adapter), Drizzle (libSQL driver), and others that support SQLite. Switching from PostgreSQL ORMs to SQLite ORMs requires schema and query changes.

ORM and Driver Compatibility

Because DB9 and Turso use different SQL dialects, they work with different ORM configurations:

ORM / Driver	DB9 (PostgreSQL)	Turso (SQLite/libSQL)
Prisma	`postgresql` provider — 89/89 (100%)	`sqlite` provider + `@prisma/adapter-libsql`
Drizzle	`pg` driver — 75/75 (100%)	`libsql` driver
SQLAlchemy	`postgresql` dialect — Tested	Not supported (SQLite dialect differs)
TypeORM	PostgreSQL driver — 147/150 (98%)	SQLite driver (different feature set)
Sequelize	PostgreSQL dialect — 87/87 (100%)	SQLite dialect
Knex	PostgreSQL client — 97/97 (100%)	SQLite3 client
GORM	PostgreSQL driver — Tested	SQLite driver

Switching between platforms requires changing ORM provider/dialect settings, not just connection strings.

Migration

Migration between DB9 and Turso is not a simple dump-and-restore because they use different SQL dialects. Moving between PostgreSQL and SQLite requires schema translation. See the Migrate from Turso guide for PostgreSQL-specific migration steps.

Key migration considerations:

Type mapping: PostgreSQL types like jsonb, uuid, timestamptz, and arrays have no direct SQLite equivalents. These must be mapped to TEXT or BLOB with application-level parsing.
Schema changes: PostgreSQL ALTER TABLE operations may need to be rewritten as create-copy-rename sequences for SQLite.
Query rewriting: PostgreSQL-specific syntax (jsonb operators, LATERAL joins, GENERATE_SERIES()) must be rewritten for SQLite.
Driver changes: PostgreSQL drivers (node-postgres, psycopg, pgx) must be replaced with libSQL clients, or vice versa.
ORM reconfiguration: ORM provider/dialect settings and type mappings need to change.

Tools like pgloader or custom ETL scripts can help, but expect a non-trivial migration effort in either direction.

Summary

DB9 is the better choice when you need PostgreSQL compatibility, AI agent integration, or application-layer SQL extensions (HTTP, files, native embeddings). It excels at multi-tenant patterns where each user or agent gets their own database, and when your stack already uses PostgreSQL ORMs and drivers.

Turso is the better choice when you need edge replication, embedded local replicas, offline-first sync, or SQLite simplicity. It excels at globally distributed read-heavy workloads and applications that benefit from a local SQLite file synced to the server.

The fundamental choice is between PostgreSQL and SQLite. If your team, tooling, and application are built around PostgreSQL, DB9 keeps you in that ecosystem with added agent and extension capabilities. If you prefer SQLite’s lightweight model and need edge replication, Turso extends SQLite into a distributed database.

DB9 vs Neon — comparison with Neon (PostgreSQL vs PostgreSQL)
DB9 vs Supabase — comparison with Supabase (database vs platform)
Compatibility Matrix — detailed feature support
Overview — what DB9 is and who it is for
Why DB9 for AI Agents — the agent-native positioning