DB9 vs Neon
DB9 and Neon are both serverless PostgreSQL-compatible databases, but they solve different problems. Neon optimizes for infrastructure flexibility — autoscaling, scale-to-zero, and efficient branching. DB9 optimizes for instant provisioning, AI agent integration, and built-in application-layer extensions.
This page is for developers evaluating both platforms. It covers the key differences honestly so you can choose the right one.
At a Glance
Section titled “At a Glance”| Capability | DB9 | Neon |
|---|---|---|
| Provisioning | Synchronous, under 1 second | Seconds (project + endpoint startup) |
| Autoscaling | No | Yes (0.25–56 CU) |
| Scale-to-zero | No (always on) | Yes (5-minute idle default) |
| Branching | Full data copy, async | Copy-on-write, instant |
| Read replicas | No | Yes (zero storage overhead) |
| Connection pooling | No built-in pooler | Built-in PgBouncer |
| Serverless driver | No (pgwire only) | Yes (@neondatabase/serverless) |
| Extensions | 9 built-in | 40+ community |
| HTTP from SQL | Yes (built-in http extension) | No |
| File system in SQL | Yes (built-in fs9 extension) | No |
| Native embeddings | Yes (built-in embedding() function) | No (pgvector only, external embeddings) |
| Agent onboarding | Yes (db9 onboard for Claude, Codex, etc.) | No |
| Anonymous access | Yes (no signup required for up to 5 databases) | No (account required) |
| Logical replication | No | Yes |
| Row-level security | No | Yes |
| LISTEN/NOTIFY | No | Yes |
| Transaction isolation | REPEATABLE READ (SERIALIZABLE accepted but downgraded) | Full SERIALIZABLE |
| Storage engine | TiKV (distributed KV) | Custom (Pageserver + Safekeeper) |
| Wire protocol | pgwire v3 | pgwire v3 |
When to Choose DB9
Section titled “When to Choose DB9”Instant database provisioning at scale. DB9 creates databases synchronously in under a second. This makes it practical to provision a database per user, per agent task, or per CI run without waiting. The SDK’s instantDatabase() creates and returns a ready-to-use connection in a single call.
AI agent workflows. DB9 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.
Application-layer extensions. DB9 includes extensions that run application logic inside the database:
http— make HTTP requests from SQL (GET, POST, PUT, DELETE)fs9— read and write files from SQL, query file contents as tablesembedding()— generate text embeddings natively (default model: text-embedding-v4, 1024 dimensions)pg_cron— schedule recurring SQL jobs
These are compiled into DB9 and available without installation. Neon does not offer equivalent built-in HTTP, file system, or native embedding 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.
When to Choose Neon
Section titled “When to Choose Neon”Variable or unpredictable workloads. Neon autoscales compute between a minimum and maximum (up to 56 CU) based on load. When idle, compute scales to zero — you pay nothing for unused databases. DB9 databases are always on with fixed compute.
Cost-sensitive development environments. Neon’s free tier includes 100 projects with scale-to-zero. Development and staging databases that sit idle most of the time cost nothing. DB9 does not scale to zero, so idle databases still consume resources.
Development branching. Neon branches are copy-on-write and instant regardless of database size. A 100 GB production database branches in milliseconds with no additional storage until writes diverge. DB9 branches are full data copies — creation is asynchronous and takes seconds to minutes depending on size, with each branch consuming its own storage.
Read-heavy workloads. Neon supports read replicas that share the same storage backend. You can scale read capacity independently without data duplication. DB9 does not support read replicas.
Broad extension ecosystem. Neon supports 40+ PostgreSQL extensions including PostGIS, pg_trgm, pgcrypto, ltree, and pg_partman. DB9 has 9 built-in extensions and cannot install community extensions. If your application depends on PostGIS or other specialized extensions, Neon is the better fit.
Serverless and edge deployments. Neon’s @neondatabase/serverless driver enables SQL queries over HTTP from edge runtimes (Cloudflare Workers, Vercel Edge Functions) where TCP connections are not available. DB9 requires pgwire (TCP), so edge functions cannot connect directly.
Full PostgreSQL feature parity. Neon supports LISTEN/NOTIFY, row-level security, table partitioning, logical replication, advisory locks, and SERIALIZABLE isolation. DB9 does not support these features. Applications that depend on them will need Neon or standard PostgreSQL.
Architecture Differences
Section titled “Architecture Differences”Storage
Section titled “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) but means branching requires a full data copy.
Neon uses a custom storage layer (Pageserver + Safekeeper) that separates compute from storage. This enables copy-on-write branching, point-in-time recovery, and read replicas that share storage. Compute endpoints connect to storage over the network and can scale independently.
Compute
Section titled “Compute”DB9 runs a custom SQL engine that parses, optimizes, and executes queries against TiKV. Each database has dedicated compute that is always running. There is no autoscaling or scale-to-zero.
Neon runs standard PostgreSQL (with custom storage hooks). Compute endpoints autoscale between configured CU ranges and suspend after idle timeout. Resumed endpoints reconnect to persistent storage.
Branching
Section titled “Branching”DB9 branches by copying all data from the parent database into a new TiKV keyspace. This is asynchronous — state progresses from CLONING to ACTIVE. Maximum 2 concurrent branch creations. Each branch is a fully independent database.
Neon branches by creating a new compute endpoint pointing to the same storage at a specific point in time. No data is copied at branch time. Writes to the branch are stored as deltas. This is instant and storage-efficient.
Extension Comparison
Section titled “Extension Comparison”| Extension / Capability | DB9 | Neon |
|---|---|---|
| pgvector (vector type + HNSW) | Built-in | Available |
| Native embedding generation | Built-in (embedding()) | Not available |
| HTTP requests from SQL | Built-in (http extension) | Not available |
| File system access from SQL | Built-in (fs9 extension) | Not available |
| pg_cron (job scheduling) | Built-in | Available |
| uuid-ossp | Built-in | Available |
| hstore | Built-in | Available |
| PostGIS | Not available | Available |
| pg_trgm (trigram search) | Not available | Available |
| pgcrypto | Not available (gen_random_uuid() works natively) | Available |
| ltree | Not available | Available |
| pg_partman | Not available | Available |
| Custom / community extensions | Not supported | 40+ supported |
ORM and Driver Compatibility
Section titled “ORM and Driver Compatibility”Both platforms support standard PostgreSQL ORMs and drivers. DB9 has tested compatibility with:
| ORM / Driver | DB9 Test Results | Neon |
|---|---|---|
| Prisma | 89/89 (100%) | Supported |
| Drizzle | 75/75 (100%) | Supported |
| SQLAlchemy | Tested (smoke + e2e) | Supported |
| TypeORM | 147/150 (98%) | Supported |
| Sequelize | 87/87 (100%) | Supported |
| Knex | 97/97 (100%) | Supported |
| GORM | Tested (smoke + e2e) | Supported |
Both platforms use pgwire v3 and work with any PostgreSQL-compatible driver (node-postgres, psycopg, pgx, JDBC).
Migration Between Platforms
Section titled “Migration Between Platforms”Moving from Neon to DB9 or vice versa uses standard pg_dump / psql workflows. See the Migrate from Neon guide for step-by-step instructions.
Key migration considerations:
- DB9 does not support Neon’s serverless driver — switch to a standard PostgreSQL driver
- DB9 does not support RLS, LISTEN/NOTIFY, or logical replication — refactor if used
- DB9 connection strings use a different format (
tenant_id.role@host:5433/postgres) - Extensions not in DB9’s built-in set will not be available
Summary
Section titled “Summary”DB9 is the better choice when you need instant database provisioning, 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.
Neon is the better choice when you need autoscaling, scale-to-zero, efficient branching, read replicas, or broad extension support. It excels at variable workloads where cost optimization and PostgreSQL feature completeness matter.
Both platforms are PostgreSQL-compatible and work with the same ORMs, drivers, and SQL. The right choice depends on which capabilities matter most for your workload.
Next Pages
Section titled “Next Pages”- Migrate from Neon — step-by-step migration guide
- DB9 vs Supabase — comparison with Supabase
- Compatibility Matrix — detailed feature support
- Overview — what DB9 is and who it is for
- Why DB9 for AI Agents — the agent-native positioning