start using PostgreSQL with your agents
sign up, open a room, and install PostgreSQL from its technologies tab.
postgresql ai agent: a real database on the room's own server
install postgresql on a room's server and its agents run psql, apply migrations, seed data, and run the test suite against a database that room owns alone.
- runs on
- room server
- installed
- per room
- category
- datastore
a database is the usual reason an agent cannot finish a task. it can write the migration but not apply it, or write the query but not run it. installing postgresql on a room's server removes that gap: the database runs on the same machine as the checkout.
what agents do with it
once it reports installed, psql and a running postgresql service are on the room's machine. agents apply the project's migrations, seed fixtures, run the test suite against a live database, and inspect the result with psql rather than reasoning about what the schema probably looks like. a query that returns the wrong rows is something they can see and iterate on.
the shape of the isolation
the database belongs to one room. two rooms never share a filesystem or a server, so a destructive migration in one project cannot reach another client's data, and a schema pinned for one engagement does not have to match anyone else's. that is the same boundary that holds for credentials and connected accounts.
example tasks
- 01
write the migration for the new column and prove it applies cleanly.
the agent writes the migration, applies it against the room's database, checks the schema with psql, and rolls it back and forward again before showing you the diff.
writebashread - 02
this query is slow. find out why.
it seeds representative data on the room server, runs explain analyze against the real planner, and reports the plan rather than an opinion about indexes.
bashgrepedit
what to know before installing
the room needs a paid server tier, and a database plus an application is the case where the 8 gb tier earns its rate. the install streams its status from pending through installing to installed, and a failed script surfaces its error. server time is metered by the hour against the same prepaid balance that pays for model usage.
how to install PostgreSQL
PostgreSQL is installed per room from the technologies tab, not once per team and not on your laptop.
- give the room a server
technologies are installed on real hardware, so the room needs a 4 GB or 8 GB tier. a room created without a server has nowhere to put them, and the install is refused rather than queued.
- open the technologies tab
room settings lists every installable technology with its status. pick PostgreSQL and the install is queued for that room's server alone.
- watch the install run
the room streams the status through pending, installing, and installed, and a failed script surfaces its error instead of leaving the room in an unknown state.
- agents use it through bash
once it reports installed, every agent in the room reaches PostgreSQL with the bash tool, on the same filesystem as the checkout they are working in. uninstalling runs the teardown script and takes it away again.
where PostgreSQL actually lives
each room owns a server for its whole life, and the technologies tab is how you decide what is on it. two rooms never share a filesystem, so a version pinned for one client cannot collide with another's.
server time is metered by the hour against the same prepaid balance that pays for model usage. the tiers and rates are on isolated rooms, and what agents may run on the machine is governed by the room's tool permissions.
faq
is this my production database?
no, and that is the point. installing postgresql puts a server on the room's own machine, so agents run migrations and tests against a database nobody else depends on. your production database stays where it is and is never reachable from the room unless you put a credential there yourself.
what does the install actually do?
it adds the postgresql apt repository, installs the server package, and enables the service so it comes up on boot. the run log ends with psql --version, so you can see exactly what landed. if psql is already present the script exits early.
can an agent run migrations against it?
yes. the database listens on the room's own machine, so an agent runs the project's migration command through the bash tool, checks the schema with psql, and reruns the suite. nothing about that touches another room.
does the data survive between sessions?
yes. the room's server is provisioned with the room and stays with it, so a seeded database is still seeded tomorrow. uninstalling postgresql from the technologies tab stops the service and removes the packages.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.