Skip to content
FlareX
Runtime & ops

Databases

Enable a per-bot Postgres schema with a scoped role and encrypted connection string.

Updated

Each FlareX bot can have its own isolated Postgres schema inside a shared cluster. "Isolated" here means a scoped role that has access to exactly one schema — no cross-bot reads, no cross-workspace reads.

Enabling the database

  1. Open your bot → Database.
  2. Click Provision database.
  3. FlareX creates a schema, a scoped role, and injects an encrypted DATABASE_URL into your bot's secrets.

Provisioning takes about 2 seconds.

How isolation works

The injected DATABASE_URL looks like:

postgresql://bot_<hash>:<password>@pg.flarex.internal:5432/flarex?search_path=bot_<hash>&options=--role%3Dbot_<hash>

The role can only:

  • See objects inside its own schema.
  • Execute queries via SET LOCAL ROLE bot_<hash> (enforced by the API).
  • Read/write within storage limits (enforced by the storage-sweep job).

The role cannot:

  • SELECT from another schema.
  • pg_dump the whole database.
  • Drop or alter the shared cluster.
  • Escape via search_path tricks — role-based ACLs prevent it.

Querying from the panel

The Database tab has a SQL console. Enter any SELECT/INSERT/UPDATE/DELETE statement and hit Run. Queries execute under SET LOCAL ROLE so you can't accidentally touch another bot's data from the panel either.

Tip

Panel queries write the full SQL to the audit log. If you're doing exploratory work on production, the trail is there when someone asks "what changed?" three months later.

Migrations

Two options:

Panel migrations (recommended for simple apps)

The Migrations tab accepts a raw SQL block per migration. FlareX:

  1. Wraps it in a transaction.
  2. Executes under SET LOCAL ROLE.
  3. Records it in bot_migrations with a checksum.

Failures roll back.

Programmatic migrations (from bot code)

Your bot can run migrations on startup using your framework of choice (Prisma, Drizzle, Kysely, node-postgres, raw SQL, whatever). The schema is ready before your container starts. Just run your migration client against DATABASE_URL at boot.

Migrations happen at deploy time

FlareX doesn't run your migrations for you. If your bot is currently running v1 and v2 adds a migration, the migration runs on v2's startup — and if it fails the deploy is marked failed and v1 stays live. You never end up with the wrong schema for the wrong bot version.

Storage limits

Your plan includes a storage quota (500 MB free, up to 200 GB enterprise). Writes are hard-blocked when the bot is over the limit — the runner returns an error to the bot's INSERT calls.

If you hit the limit:

  • Free tier: upgrade your plan or delete older rows.
  • Paid tiers with overage enabled: writes continue and overage is billed at the per-GB-month rate. Enable overage in Settings → Billing.

The storage sweep runs hourly and measures pg_total_relation_size per schema.

Backups

Automatic daily pg_dump of the shared cluster. Per-bot restore: open a support ticket with the bot ID and a timestamp — we can restore an individual schema from the dump.

Deleting a database

Deleting a bot also deletes its schema (after the 30-day tombstone). There's no standalone "delete just the data, keep the bot" option — if you need that, drop tables manually via the SQL console.

Limits

  • Max schema size per bot: plan-dependent, 200 GB cap on Enterprise.
  • Max concurrent connections per bot: 10 (the pool inside your bot container).
  • No extensions beyond pgcrypto, uuid-ossp, citext, unaccent. Ping support if you need others.
PreviousDiscord webhooksNextBilling
Databases · FlareX