Supapool provisions a full Supabase instance (Postgres, Auth, Storage) in roughly 400 milliseconds and tears it down when your agent exits. Instead of sharing a connection pool or relying on row-level security, each agent gets its own database. This shifts the isolation boundary from application logic to infrastructure and changes how you think about cost, cleanup, and cross-contamination.
Why Per-Agent Databases Matter
Traditional multi-tenant patterns use one database with row-level security, schema separation, or connection pooling. Agents that generate SQL, run migrations, or manipulate schema break these models. A coding agent that drops a table or rewrites a migration file can corrupt shared state.
Supapool sidesteps this by making databases disposable. Each agent session gets:
- A clean Postgres instance
- Supabase Auth and S3-compatible Storage
- Automatic migration application from
supabase/migrations - Credential injection into the agent’s environment
- Automatic teardown when the process exits
The CLI wraps any command:
npx @supapool/cli run -- npm run devThe wrapper acquires a lease, applies migrations, injects environment variables, renews the lease while the command runs, and releases the instance on exit.
Provisioning Speed and Lifecycle
Traditional Supabase branches take minutes to spin up and bill like production instances. Supapool claims 400ms cold starts by keeping a warm pool of pre-initialized instances. When you request a lease, you get an already-running instance with a clean schema.
Lease mechanics:
- Default TTL: 30 minutes
- Automatic renewal while the wrapped command is alive
- Immediate release on process exit
- No manual cleanup required
The instance is ephemeral. If your agent crashes or the lease expires, the database disappears. This makes Supapool unsuitable for persistent state but ideal for test runs, parallel agent swarms, or throwaway development environments.
Isolation Model Comparison
| Approach | Isolation Boundary | Cross-Contamination Risk | Cost Structure | Setup Time |
|---|---|---|---|---|
| Shared pool + RLS | Application logic | High (schema changes, migrations) | Fixed per cluster | Instant |
| Schema-per-tenant | Database schema | Medium (connection limits, locks) | Fixed per cluster | Seconds |
| Supabase branches | Full instance | Low (separate databases) | Per-branch billing | Minutes |
| Supapool | Full instance | None (ephemeral, isolated) | Per-lease metering | ~400ms |
Supapool eliminates cross-contamination by making each instance single-tenant and short-lived. The trade-off is cost: you pay for compute and storage during the lease, even if the agent is idle.
Environment Injection and Compatibility
The CLI injects standard Supabase variables plus framework-specific aliases:
SUPABASE_URL,SUPABASE_ANON_KEY,SUPABASE_SERVICE_ROLE_KEYDATABASE_URL(Postgres connection string)- Public prefixes for Next.js, Vite, Astro, Svelte, Expo, Gatsby, Nuxt
- Prisma and
PG*connection variables
Secret keys are never assigned to browser-public variables. The CLI also sets SUPAPOOL_INSTANCE_ID to identify the lease.
Your repository’s .env files are never modified. All credentials live in the process environment, so agents can’t accidentally commit secrets or overwrite local config.
Migration Handling
On lease acquisition, Supapool applies every .sql file in supabase/migrations in filename order. This mirrors the Supabase CLI migration flow but happens automatically before your command starts.
Failure modes:
- Migration syntax errors abort the lease and return an error
- Missing migration files are ignored (the instance starts empty)
- Schema drift between migrations and application code causes runtime errors, not provisioning errors
If your agent generates new migrations during the run, they won’t be applied to the current instance. You’d need to release and re-acquire to pick up new files.
Cost and Metering
Supapool is free during beta. Post-beta pricing will likely meter by lease duration and instance size. The economic model is closer to serverless functions than traditional database hosting: you pay for active time, not reserved capacity.
Cost drivers:
- Lease duration (default 30 minutes, renewable)
- Instance size (Postgres memory, CPU, storage)
- Number of concurrent leases
Because instances are ephemeral, you don’t pay for idle databases. But if your agent runs for hours, the cost accumulates. This makes Supapool expensive for long-running agents and cheap for short, parallel tasks.
Observability and Debugging
The CLI exposes accounts, usage, and cost through the CLI and API. There is no dashboard. This is intentional: the design assumes agents will query their own usage and pipe it into logging or cost-tracking systems.
What you can observe:
- Active leases and their TTLs
- Total lease time per account
- Instance IDs for correlation with logs
What you can’t observe:
- Query performance inside the instance
- Storage usage during the lease
- Connection pool saturation
If your agent hangs or leaks connections, you’ll see the lease renew but won’t get Postgres-level metrics. You’d need to connect directly with psql or a monitoring agent during the lease.
Security Boundaries
Each instance is network-isolated. Agents can’t reach each other’s databases, even if they know the instance ID. Credentials are scoped to the lease and expire when the instance is released.
Attack surface:
- Leaked
SUPABASE_SERVICE_ROLE_KEYgrants full access to that instance (but only for the lease duration) - Agents that log credentials to persistent storage create a credential-stuffing risk
- No rate limiting on lease acquisition (during beta)
The ephemeral nature limits blast radius. If an agent is compromised, the attacker has at most 30 minutes before the instance disappears. But if the agent runs in a loop, the attacker can keep acquiring new leases.
When to Use Supapool
Good fit:
- Coding agents that generate migrations or modify schema
- Parallel test runs that need isolated databases
- Agent swarms where each agent needs its own state
- Development environments that reset frequently
Bad fit:
- Long-running agents (cost accumulates)
- Agents that need persistent state across sessions
- Production workloads (ephemeral instances can’t handle failover)
- High-frequency, short-lived tasks (400ms provisioning adds latency)
Technical Verdict
Supapool solves the isolation problem for multi-tenant agent platforms by making databases disposable. The 400ms provisioning time is fast enough for most agent workflows, and the automatic cleanup prevents resource leaks. The cost model works for short, parallel tasks but becomes expensive for long-running agents. If your agents manipulate schema or run migrations, Supapool is cleaner than row-level security or shared pools. If your agents need persistent state or run for hours, stick with traditional hosting and accept the cross-contamination risk.