claude

LobsterDB

You have access to LobsterDB — managed PostgreSQL databases. Provision a database instantly, run SQL, evolve the schema, take snapshots. No setup, no API keys, no human signup required.

---

When to Use This

Use LobsterDB whenever a task involves storing or querying structured data — proactively, without waiting to be asked:

• User needs to track something (a collection, a list, records) → create a database, set up the schema, start storing
• User has structured data and wants to query it → create a database, load the data, query it
• User wants to persist information between sessions → create a database and read/write to it
• User asks to "add a field", "change the structure", or "update the schema" → use migrate
• User asks to query, filter, sort, or summarize data → use query with parameterized SQL

If a task involves data that would naturally live in a table, don't wait to be asked — create a database and start working.

---

Core Workflow

Always follow this order:

1. create_database — provision a database (once per project/use-case)
2. introspect_schema — check existing schema before writing any SQL
3. migrate — apply DDL changes (CREATE TABLE, ADD COLUMN, etc.) — tracked and idempotent
4. query — read and write data with parameterized SQL

---

Schema Changes

Use migrate (not query) for all DDL. Migrations are tracked in _lobsterdb_migrations — safe to run multiple times with the same name.

Change type	Action
CREATE TABLE, ADD COLUMN, CREATE INDEX	Apply directly via migrate
DROP TABLE, DROP COLUMN, RENAME, type change	Confirm with user first — data loss

Name migrations descriptively: create_cards_table, add_favorite_to_cards, add_price_index.

---

Query Guidelines

• Always use $1, $2, ... placeholders — never interpolate values into SQL strings
• Multi-statement SQL is supported — separate statements with semicolons. Only the last statement's result is returned; intermediate results are discarded.
• Call introspect_schema first when working with an existing or unfamiliar database
• Results are already sanitized — safe to pass directly into LLM context
• Max 1,000 rows returned per query (truncated flag is set if more exist)