Frequently Asked Questions

What is DB9?

DB9 is a serverless PostgreSQL-compatible database built on TiKV. It speaks the PostgreSQL wire protocol, so any tool that connects to Postgres — psql, Prisma, Drizzle, SQLAlchemy, or a raw driver — connects to DB9 with no adapter needed. What makes DB9 different is what ships inside the server: vector search with built-in embeddings, a queryable file system (fs9), HTTP calls from SQL, scheduled jobs via pg_cron, and zero-copy branching. These capabilities are compiled into the server, not bolted on through external services. DB9 is designed for AI agents and developers who need instant provisioning. An agent can create a database in under a second using the CLI or TypeScript SDK, store structured data alongside embeddings and files, call external APIs from SQL, and tear the database down when the task is done — all through standard PostgreSQL. Anonymous trial databases work immediately with no account, credit card, or email required. Run db9 claim to remove the 5-database limit when you are ready.

How is DB9 different from Neon?

DB9 and Neon are both serverless PostgreSQL-compatible databases, but they solve different problems. Neon optimizes for infrastructure flexibility — autoscaling between 0.25 and 56 CU, scale-to-zero on idle, and instant copy-on-write branching. DB9 optimizes for instant provisioning, AI agent integration, and built-in application-layer extensions. DB9 creates databases synchronously in under a second; Neon takes seconds for project and endpoint startup. DB9 branches are full data copies (asynchronous, seconds to minutes); Neon branches are copy-on-write and instant regardless of database size. DB9 includes extensions that Neon does not: native embedding() generation, fs9 file system access, HTTP calls from SQL, CHUNK_TEXT() for RAG, and Parquet import. Neon supports extensions DB9 does not: PostGIS, pg_trgm, pgcrypto, ltree, logical replication, LISTEN/NOTIFY, read replicas, and full SERIALIZABLE isolation. Choose DB9 for agent workflows, multi-tenant provisioning, and SQL-layer application logic. Choose Neon for variable workloads, cost-sensitive staging environments, broad extension support, or efficient branching on large databases.

How is DB9 different from Supabase?

DB9 is a database. Supabase is a full application platform — PostgreSQL database plus authentication, file storage, realtime subscriptions, edge functions, and an auto-generated REST API. They are not direct substitutes. DB9 competes with Supabase's database layer only; everything else in Supabase has no equivalent in DB9. DB9 provisions databases synchronously in under a second, supports anonymous access without signup, and includes application-layer SQL extensions: native embedding() generation, fs9 file system access, HTTP calls from SQL, CHUNK_TEXT() for RAG pipelines, and Parquet import. Supabase runs standard PostgreSQL with the full extension ecosystem (PostGIS, pg_trgm, pgcrypto), LISTEN/NOTIFY, logical replication, SERIALIZABLE isolation, built-in connection pooling via Supavisor, and CDN-backed file storage. Choose DB9 when you want a fast, programmable database that agents can create and discard without a surrounding platform. Choose Supabase when you need a complete application backend with auth, realtime, storage, and edge functions provided out of the box.

Can I use DB9 with Prisma/Drizzle/SQLAlchemy?

Yes. DB9 speaks the PostgreSQL wire protocol, so any ORM or driver that supports standard PostgreSQL works without code changes or adapters. Prisma passes 89 of 89 compatibility tests against DB9. Drizzle passes 75 of 75. SQLAlchemy has been tested in both smoke and end-to-end suites. TypeORM: 147 passing, 0 failing, 3 skipped. Sequelize passes 87 of 87. Knex passes 97 of 97. GORM has been tested with smoke and end-to-end coverage. To connect, use the connection string returned by db9 db connect or the TypeScript SDK's instantDatabase() call. Set sslmode=require or the equivalent TLS option for your driver. For Prisma, use the postgresql provider. For Drizzle, use the pg or postgres driver with the standard connection string. For SQLAlchemy, use the postgresql+psycopg2 dialect. DB9 does not require any DB9-specific package — your existing ORM setup works as-is. See the Connect docs for per-ORM connection guides covering Prisma, Drizzle, SQLAlchemy, TypeORM, Sequelize, Knex, and GORM.

Does DB9 support pgvector?

Yes. DB9 includes a pgvector-compatible vector type with HNSW indexing built into the server. You can store vectors, create HNSW indexes, and run similarity searches using the standard pgvector operators (<->, <#>, <=>). Beyond pgvector compatibility, DB9 also ships a native embedding() function that generates and caches text embeddings server-side without any external embedding API. Enable it once per database with CREATE EXTENSION embedding, then call embedding('your text')::vector in any SQL statement to generate a 1024-dimension vector using the default text-embedding-v4 model. This lets you store, index, and search embeddings entirely in SQL with no application-layer embedding client. DB9 also includes CHUNK_TEXT() for splitting documents into overlapping chunks before embedding — useful for RAG pipelines. Embeddings are generated server-side, cached to avoid redundant calls, and subject to per-tenant concurrency limits of 5 concurrent requests by default. All vector operations use standard pgvector syntax, so existing pgvector code runs on DB9 without modification.

How fast does DB9 provision a database?

DB9 provisions databases synchronously in under a second. Unlike platforms that create a project, configure endpoints, and wait for compute to start, DB9 creates an isolated TiKV keyspace and returns a ready connection string in a single operation. From the CLI, db9 create --name myapp returns a live database immediately. From the TypeScript SDK, instantDatabase({ name: 'myapp' }) returns a connectionString in one await. No signup is required — anonymous accounts work on first use. The CLI auto-registers an anonymous account and creates the database in one step. Anonymous accounts support up to 5 databases; run db9 claim to remove that limit by linking an identity. This provisioning speed makes database-per-user, database-per-agent-task, and database-per-CI-run patterns practical without orchestration. Each database is a fully isolated keyspace in TiKV — tenants share infrastructure but never data. The same sub-second guarantee applies whether you are creating your first database or your thousandth through the API.

What are DB9's database limits?

DB9 anonymous accounts support up to 5 databases. Run db9 claim to link an identity and remove that limit. For the fs9 file system extension, individual files are limited to 100 MB, with a 128 MB per-operation read budget. For the HTTP extension, limits per SQL statement are 100 requests maximum, 20 concurrent requests per tenant, 1 MB maximum response size, 256 KB maximum request body, and a 5-second per-request timeout. HTTP calls are HTTPS-only and private or loopback IP addresses are blocked for SSRF protection. For the embedding() function, the per-tenant concurrency limit is 5 concurrent requests by default. For database branching, a maximum of 2 concurrent branch creations are allowed per database. DB9 does not currently support LISTEN/NOTIFY, table partitioning, logical replication, or advisory locks that are cross-process or global. Transaction isolation is REPEATABLE READ; SERIALIZABLE requests are accepted but downgraded to REPEATABLE READ with a warning (TiKV provides snapshot isolation). For a full list of SQL constraints, see the Limits and Constraints reference page at /docs/sql/limits/.

How do I give Claude Code its own database?

Run db9 onboard --agent claude from your terminal. This installs a DB9 skill file that teaches Claude Code how to create databases, run SQL, manage files, and use branching — all through the DB9 CLI. The skill is placed at ~/.claude/skills/db9/ by default (user scope, available across all projects). To scope it to one project only, add --scope project. To install at both levels, use --scope both. Preview what will be installed without writing anything: db9 onboard --agent claude --dry-run. After onboarding, Claude Code can call db9 create, db9 db sql, db9 fs cp, db9 branch create, and other CLI commands as part of its normal workflow. Anonymous accounts work immediately — no API key setup required for Claude Code to start using DB9. The same onboard command supports other agents: codex for OpenAI Codex, opencode for OpenCode, and agents for a generic .agents directory. Each agent gets the same skill file so it can provision, query, and manage databases through natural-language instructions backed by DB9's CLI.

Does DB9 support branching?

Yes. DB9 supports database branching through the CLI and TypeScript SDK. To create a branch: db9 db branch create myapp --name preview. Branches are full data copies of the parent database, created asynchronously. State progresses from CLONING to ACTIVE as the copy completes. Each branch is a fully independent database with its own isolated TiKV keyspace — branches share history with the parent but diverge completely on write. A maximum of 2 concurrent branch creations are allowed per database. Branches are useful for preview environments, schema experiments, rollback points, and safe testing of destructive operations. Delete a branch with db9 branch delete when you no longer need it. Important difference from Neon: Neon branches use copy-on-write storage and are instant regardless of database size. DB9 copies all data, so branch creation takes seconds to minutes and each branch consumes its own storage. DB9 branching works well for agent workflows and CI with small-to-medium databases.

What is fs9?

fs9 is DB9's built-in queryable file system extension. It lets you read, write, and query files directly from SQL without ETL pipelines or external loaders. Enable it with CREATE EXTENSION fs9. Once enabled, SELECT * FROM extensions.fs9('/data/users.csv') reads a CSV file as a SQL table with automatic schema inference. fs9 supports CSV, JSON Lines, and Parquet formats. Write files from SQL with fs9_write(), check existence with fs9_exists(), and import Parquet files with read_parquet() or COPY FORMAT parquet. Files are accessible through three interfaces: SQL queries via the fs9 extension functions, CLI commands (db9 fs cp, db9 fs sh, db9 fs ls), and a FUSE mount via db9 fs mount that exposes the DB9 file system as a local directory. Individual files are limited to 100 MB with a 128 MB per-operation read budget. fs9 is especially useful for AI agents that produce and consume files — logs, CSVs, JSON exports, Parquet snapshots — keeping them co-located with the SQL data they relate to.