DB9 vs Supabase
DB9 is a serverless PostgreSQL-compatible 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. Everything else in Supabase (Auth, Storage, Realtime, Edge Functions, PostgREST) has no equivalent in DB9. This page helps you understand which approach fits your project.
At a Glance
Section titled “At a Glance”| Capability | DB9 | Supabase |
|---|---|---|
| Product scope | Database only | Full application platform |
| PostgreSQL database | Yes | Yes (standard PostgreSQL) |
| Authentication | No | Yes (GoTrue) |
| File storage | fs9 extension (SQL-based) | Yes (S3-backed, CDN) |
| Realtime subscriptions | No | Yes (CDC + LISTEN/NOTIFY) |
| Auto-generated REST API | No | Yes (PostgREST) |
| Edge Functions | No | Yes (Deno) |
| Row-level security | No | Yes |
| Provisioning speed | Synchronous, under 1 second | Seconds to minutes (full project setup) |
| Agent onboarding | Yes (db9 onboard) | No |
| Anonymous access | Yes (no signup, up to 5 databases) | No (account required) |
| Native embeddings | Yes (embedding() function) | No (pgvector only, external embeddings) |
| HTTP from SQL | Yes (built-in http extension) | Yes (pg_net extension) |
| Connection pooling | No built-in pooler | Yes (Supavisor) |
| Extensions | 9 built-in | 40+ (PostGIS, pg_trgm, pgcrypto, etc.) |
| LISTEN/NOTIFY | No | Yes |
| Logical replication | No | Yes |
| Transaction isolation | REPEATABLE READ (SERIALIZABLE accepted but downgraded) | Full SERIALIZABLE |
| Wire protocol | pgwire v3 | pgwire v3 |
When to Choose DB9
Section titled “When to Choose DB9”You want a database, not a platform. If your application already has its own auth, storage, and API layer — or you prefer to compose these from separate services — DB9 gives you a PostgreSQL-compatible database without bundled platform services. There is no auth system to configure, no storage policies to manage, and no PostgREST to learn.
Instant database provisioning at scale. DB9 creates databases synchronously in under a second. The SDK’s instantDatabase() 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.
AI agent workflows. DB9 is built 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 or infrastructure needed.
Application-layer SQL extensions. DB9 includes extensions that bring application logic into SQL:
http— make HTTP requests from SQL (GET, POST, PUT, DELETE, PATCH, HEAD)fs9— read, write, and query files from SQL; parse JSONL/CSV/TSV 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 always available. Supabase has pg_net for outbound HTTP webhooks and pg_cron, but does not offer built-in file system access or native embedding generation.
No-signup developer experience. Install the CLI and create a database immediately — no account creation, no email verification. Anonymous accounts support up to 5 databases and can be upgraded later with db9 claim.
When to Choose Supabase
Section titled “When to Choose Supabase”You want a full backend, not just a database. Supabase bundles authentication (GoTrue), file storage (S3-backed with CDN), realtime subscriptions (CDC), edge functions (Deno), and an auto-generated REST/GraphQL API. If your project needs most of these, Supabase provides them as a single integrated platform. Building the same stack from separate services takes more effort.
Client-side database access. Supabase’s auto-generated PostgREST API and client libraries (@supabase/supabase-js) let frontend applications query the database directly with row-level security enforcing access control. DB9 requires pgwire (TCP) and does not expose an HTTP SQL endpoint — all database access must go through a backend or server-side code.
Row-level security. Supabase projects heavily use RLS to enforce per-user data access at the database level. This is core to Supabase’s security model for client-side access. DB9 does not support RLS — access control must be enforced in your application layer.
Realtime features. Supabase Realtime uses PostgreSQL’s LISTEN/NOTIFY and change data capture to push database changes to connected clients. DB9 does not support LISTEN/NOTIFY. If your application needs live updates when data changes, Supabase handles this natively.
Broad extension ecosystem. Supabase supports 40+ PostgreSQL extensions including PostGIS, pg_trgm, pgcrypto, ltree, and pg_graphql. DB9 has 9 built-in extensions and cannot install community extensions.
Standard PostgreSQL. Supabase runs standard PostgreSQL with full feature parity — SERIALIZABLE isolation, table partitioning, table inheritance, advisory locks, logical replication, and all PL/pgSQL capabilities. DB9’s custom SQL engine has compatibility gaps in these areas.
Dashboard and visual tools. Supabase includes a web dashboard with a SQL editor, table viewer, auth management, storage browser, and logs. DB9 is CLI-first with no web dashboard.
Architecture Differences
Section titled “Architecture Differences”DB9 is a database service. You get a PostgreSQL-compatible database with built-in extensions. Everything else — auth, file storage, APIs, realtime — is your responsibility.
Supabase is an application platform. Each project includes a PostgreSQL database, GoTrue auth server, S3-compatible storage, Realtime server, PostgREST API, and Deno edge function runtime. These services are pre-integrated and share the same project.
Storage engine
Section titled “Storage engine”DB9 uses TiKV, a distributed key-value store. Each database gets an isolated keyspace. This enables instant provisioning but means branching requires full data copies.
Supabase uses standard PostgreSQL with its default storage engine. Compute and storage are not separated — scaling requires upgrading the instance.
Multi-tenancy
Section titled “Multi-tenancy”DB9 supports database-per-tenant natively. Creating thousands of databases is practical because provisioning is synchronous and sub-second. The SDK’s instantDatabase() is idempotent and handles the full lifecycle.
Supabase is designed around one project per application (or a small number of projects). Multi-tenancy is typically handled within a single database using schemas or RLS policies, not by creating separate projects per tenant.
Extension Comparison
Section titled “Extension Comparison”| Extension / Capability | DB9 | Supabase |
|---|---|---|
| pgvector (vector type + HNSW) | Built-in | Available |
| Native embedding generation | Built-in (embedding()) | Not available |
| HTTP requests from SQL | Built-in (http extension) | pg_net (async webhooks) |
| 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 |
| pg_graphql | Not available | Available |
| pgsodium (encryption) | Not available | Available |
| Custom / community extensions | Not supported | 40+ supported |
ORM and Driver Compatibility
Section titled “ORM and Driver Compatibility”Both platforms work with standard PostgreSQL ORMs and drivers. DB9 has tested compatibility with:
| ORM / Driver | DB9 Test Results | Supabase |
|---|---|---|
| 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 |
Supabase additionally provides its own client library (@supabase/supabase-js) that wraps PostgREST. DB9 does not have an equivalent — use standard PostgreSQL drivers or ORMs.
Migration Between Platforms
Section titled “Migration Between Platforms”Moving from Supabase to DB9 uses standard pg_dump with schema exclusions for Supabase’s internal schemas. See the Migrate from Supabase guide for step-by-step instructions.
Key considerations:
- DB9 replaces only the database — plan replacements for Auth, Storage, Realtime, and Edge Functions
- RLS policies must be moved to application-level access control
- The Supabase client library must be replaced with a standard PostgreSQL driver or ORM
- DB9 connection strings use a different format (
tenant_id.role@host:5433/postgres)
Summary
Section titled “Summary”DB9 is the better choice when you want a standalone PostgreSQL-compatible database with instant provisioning, AI agent integration, and built-in SQL extensions for HTTP, files, and embeddings. It fits teams that compose their own backend from separate services.
Supabase is the better choice when you want a full application backend — database, auth, storage, realtime, and API — in one integrated platform. It fits teams that want to ship quickly with batteries included, especially for client-side-heavy applications that rely on RLS and PostgREST.
The decision is architectural: do you want a database or a platform? If you already have (or prefer to build) your own auth, storage, and API layers, DB9 gives you a fast, agent-friendly database. If you want those services bundled and integrated, Supabase provides them.
Next Pages
Section titled “Next Pages”- Migrate from Supabase — step-by-step migration guide
- DB9 vs Neon — comparison with Neon (database vs database)
- Compatibility Matrix — detailed feature support
- Overview — what DB9 is and who it is for
- Why DB9 for AI Agents — the agent-native positioning