---
title: "postgresql ai agent: a real database on the room's own server"
description: "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."
url: "https://aldena.ai/integrations/postgresql"
---

# postgresql ai agent: a real database on the room's own server

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

- **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.

  tools: `write` -> `bash` -> `read`

- **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.

  tools: `bash` -> `grep` -> `edit`

## 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.

## 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.