Standalone Databases

Projects get a database per environment automatically. Standalone databases are the other half: SQLite databases you create on their own — for prototypes, scratch data, one-off scripts, or data you want to share across projects.

They live under Databases in Creator Studio, next to Projects. The same page also lists your projects' databases (per environment), so every database in your organization is in one place — click one to manage it from its project.

What you get

Nothing is injected into a project automatically — you decide where the connection string goes.

Create one

In Creator Studio, go to Databases → New Database, give it a name, and it's ready in seconds. The connection URL and the first auth token are shown once — copy the token before closing the dialog.

From the CLI:

buildspace db create "Scratch data"

Created database 'Scratch data' (scratch-data)

  Connection URL: libsql://bs-db-1a2b3c4d-scratch-data-9f8e7d.turso.io
  Auth token:     eyJhbGciOi...

Store the token now — it is hashed on save and cannot be shown again.

Connect to it

Standalone databases are plain libSQL — connect with any libSQL client. Keep the token in an environment variable.

import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const client = createClient({
  url: process.env.BUILDSPACE_DB_URL!,
  authToken: process.env.BUILDSPACE_DB_TOKEN!,
});

export const db = drizzle(client);

The console

Click into a database and open Console to work with the data directly:

• Schema tree — tables and views with their columns, primary keys, and foreign keys.
• Browse — paginated, sortable rows. With editing mode on you can edit cells inline, add rows, and delete rows.
• SQL — run statements against the database, with results in a grid and a local query history.
• Ask for SQL — describe what you want in plain English. The assistant reads your schema server-side and drafts SQLite for you to review and run.

Guardrails that always apply:

• Queries run read-only by default. Writes require turning on editing mode.
• Every console call re-checks that the database belongs to your organization.
• Tokens are minted server-side, are short-lived, and never reach the browser.
• Row caps, LIMIT clamps, and a statement timeout keep a runaway query from inflating your metered rows-read.

Tokens

Each database has its own tokens. Mint one per consumer so you can revoke narrowly.

buildspace db token create scratch-data --label analytics --read-only
buildspace db token list scratch-data
buildspace db token revoke scratch-data <tokenId>

Rotate (from the database page in Studio) invalidates every token on the provider and issues a fresh full-access one — use it when a token leaks.

Query from the terminal

buildspace db shell scratch-data --sql "select count(*) from users"

# writes need an explicit flag
buildspace db shell scratch-data --write --sql "delete from sessions where expires_at < unixepoch()"

# or pipe a file
cat migration.sql | buildspace db shell scratch-data --write

Attach one to a project

From the database page, Attach to a project points a project environment at this database: it mints a fresh token and rewrites that environment's BUILDSPACE_DB_URL and BUILDSPACE_DB_TOKEN, then syncs them to the hosting provider. The project's original database keeps its data but stops being used.

Delete

Deleting destroys the database and all of its data on Turso — there is no undo. Studio requires you to type the database name; the CLI requires --yes.

buildspace db delete scratch-data --yes