CTA keyword: AGENTDB · from the @compedge.ai x @am_roshh carousel
Supabase says it is acquiring Turso, a company that rebuilt SQLite in Rust so one server can manage millions of small databases, and that this makes it possible to provision a database for each agent on demand (Supabase blog, 2 Oct 2026). Whether you use either company or neither, the pattern is worth copying. Here are 5 rules for giving an AI agent a database of its own.
What happened
- The announcement. On 2 Oct 2026 Supabase CEO Paul Copplestone wrote that Supabase is acquiring Turso. The post says agents are spinning up millions of databases for prototypes, explorations, dashboards and apps, and that this needs "an evolution in database infrastructure" (Supabase blog, 2 Oct 2026).
- The scale. Supabase says it is already launching over one million databases per week (Supabase blog).
- The architecture. According to the post, Turso rebuilt SQLite in Rust and built a cloud platform where a single server can manage millions of databases, loading them when needed and suspending them when not. The post says this makes it possible to provision a database for each agent on demand, as Superhuman, Sauna.ai, CTO.new and Mastra do (Supabase blog).
- What stays the same. For existing users, the post says nothing changes: Supabase keeps building around Postgres and Turso keeps working on SQLite. The post describes SQLite as well suited to small, on-demand workloads and Postgres as what you want as your application scales (Supabase blog).
- The press release. PR Newswire carried the announcement under the headline "Supabase Announces $150M in New Funding and Turso Acquisition" (2 Oct 2026, 13:00 UTC).
The 5 rules below are our own general guidance for anyone letting agents store data. They are ours, not Supabase's or Turso's, and they are not a description of either product.
The 5 rules
1. One database per agent (or per task)
Why: a shared database lets one agent's bad write land in another agent's data, and afterwards you can't tell which agent wrote what. Supabase's post describes provisioning a database for each agent on demand, which is the same idea.
How:
- One database (or one schema with its own credentials) per agent or per task, never a shared one.
- Name it after the agent and the job, for example
research-agent-acme-q4. - Give each its own login. The agent's key should open only its own database.
- Keep a short list of which databases exist, who owns them and what they are for.
Example: a research agent that collects competitor notes gets research-agent-acme-q4 and nothing else. Your reporting agent gets its own database and reads a copy of the findings you choose to hand over. If the research agent writes junk, only that database is affected.
2. Start small. Move to Postgres when it grows.
Why: most agent work starts as a prototype, a scratch table or a one-off dashboard. Supabase's post says SQLite is well suited to small, on-demand workloads and Postgres is what you want as your application scales. Starting small keeps the first version fast to set up, and you move up when the work earns it.
How:
- Start with the smallest thing that works: a file-sized database for one agent and one job.
- Decide your move-up triggers now. Ours: more than one agent or person needs the same data, you need several writers at once, or you need proper backups and access control.
- When a trigger fires, move that database to Postgres. Don't wait for it to hurt.
Example: a lead-research agent starts with one small database of company names and notes. Three weeks later your sales team wants to query it too, which is a trigger, so you move it to Postgres with a migration.
3. Make it cheap to create and cheap to delete
Why: Supabase's post says agents should be able to create a database as easily as creating a file, with as little concern about cost. If creating one is a chore, people reuse one database for everything (see rule 1). If deleting one is scary, old databases pile up with data nobody owns.
How:
- One command or script to create a database from a template, and one to delete it.
- Throwaway databases for every test run. Delete them when the run ends.
- Put an owner and an expiry date in the name or a label. Review expired ones weekly.
- Export before you delete, so a delete is never the only copy.
Example: your test suite spins up a fresh database per run from the template, seeds it, runs the agent, then deletes it. Nothing from Tuesday's test can leak into Wednesday's.
4. Log every write
Why: an agent that writes to a database is making decisions you may need to review. A log is how you find out what it stored, when and why. A log the agent can edit is not one you can trust.
How:
- Record every write: time, agent name, database, table, what changed and the task that caused it.
- Keep the log somewhere the agent's key can't edit or delete, such as a separate log project or an append-only table.
- Log deletes and schema changes too, not just inserts.
- Read the log before you trust the data, at least for the first runs.
Example: every insert and update by the research agent lands in an audit_log table that only your admin login can change. On Friday you skim it: 214 inserts to notes, 0 deletes. If a DROP TABLE line ever appears, you know to look.
5. Keep one schema from prototype to production
Why: Supabase's post says builders should have the same developer experience from prototyping to production. A prototype whose schema can't survive the move has to be rebuilt, and rebuilds lose data and time.
How:
- Keep the schema in migration files in git, not in somebody's memory or a dashboard click.
- Use plain, common column types. Avoid engine-specific features until you need them.
- Rehearse the move once while the data is small: run the same migrations against a Postgres copy and compare results.
- Keep the agent's queries in code, so you can run them against both and see the same answer.
Example: your notes table starts life as three columns in a small database. Because the schema lives in 001_notes.sql in git, moving it to Postgres later is a rehearsed step, not a rewrite.
Before you give an agent a database: fill this in
Copy this, fill it in for each agent, and keep it with the agent's setup notes.
AGENT: ______________
OWNER (person): ______________
JOB (one line): ______________
DATABASE
Name (agent + job): ________
Engine today: ______________
Own login only: [ ] yes
Made from (template): _____
SIZE AND MOVE-UP
Expected size: ______________
Move to Postgres when:
______________________________
Schema kept in (git): _____
LIFECYCLE
Delete script: ______________
Expires on: ______________
Export before delete: [ ] yes
LOGGING
Every write logged to:
______________________________
Agent can edit the log: [ ] no
Reviewed by, how often:
______________________________
REVIEW DATE: ______________
Sources
- Supabase blog (Paul Copplestone), Supabase is acquiring Turso, 2 Oct 2026
- PR Newswire, "Supabase Announces $150M in New Funding and Turso Acquisition", 2 Oct 2026, 13:00 UTC (headline)
The news section reflects the Supabase blog post and press release headline published on 2 Oct 2026. The 5 rules are CompEdge's own general guidance, not a description of Supabase's or Turso's products.