Standalone Databases

Spin up SQLite databases that aren't tied to a project, and browse or query them from Creator Studio.

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.

What you get

Concept	Detail
Engine	Turso (libSQL, SQLite-compatible)
Scope	Owned by your organization, not by a project
Quota	25 databases per organization by default
Credentials	A connection URL plus tokens you mint yourself (full-access or read-only)
Console	Built-in table browser, row editor, and SQL runner
Metering	Storage and rows read/written synced hourly, shown on your billing page

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.

db.ts

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

On this page