Databases

Elula can give each app its own Postgres database. The databases live on a Cloud SQL instance in your own Google Cloud project, which Google bills to you directly. Each app gets its own database and its own user, and its connection string is set as DATABASE_URL when it deploys.

Set up the workspace instance

All apps in a workspace share one Cloud SQL instance (Postgres 15). A workspace owner creates it once:

1. Open Databases in the dashboard.
2. Click Get started and pick a size:

3. Click Provision database. Creating the instance takes about 5-10 minutes. You can leave the page.

The instance is created in your workspace's Google Cloud region.

Or from the command line (workspace owners):

elula db server create --size starter --wait   # sizes: starter, small, large
elula db server                                # not created / being created / ready / failed

--wait keeps checking until the instance is ready. Without a terminal (scripts, AI agents) add -y to confirm the cost.

Add a database to an app

When you create the app:

elula init --database

In the dashboard, turn on Provision a PostgreSQL database under Advanced / optional when creating the app.

For an existing app:

elula db provision
elula db          # check whether it's ready
elula deploy      # redeploy so the app gets DATABASE_URL

You can also pick the app on the Databases page. Adding a database to an existing app needs the app's owner, or a workspace owner or admin.

Connect from your app

Read DATABASE_URL from the environment. It looks like this:

postgresql://<user>:<password>@localhost/<database>?host=/cloudsql/<project>:<region>:<instance>

The app connects to Cloud SQL through a Unix socket that Cloud Run mounts at /cloudsql. Most Postgres drivers and ORMs accept this URL as is.

• Don't set DATABASE_URL yourself. If the app has a managed database, Elula's value replaces yours.
• The socket only exists inside the deployed app. This URL doesn't work from your laptop.
• DATABASE_URL is stored encrypted by Elula and set as an environment variable on each deploy.

See connection details

elula db          # database name, user and instance
elula db --json

Editors can reveal the full connection URL in the dashboard. Revealing it is recorded in the audit log.

Run migrations

Write your migration as a SQL file and run it:

elula db migrate migrations/001_create_users.sql
elula db migrate 002_add_index.sql --name add-users-email-index
elula db migrate 003_orders.sql --down 003_orders_down.sql

• The name defaults to the file name without .sql.
• --down stores rollback SQL with the migration.
• Every run is recorded, including failed ones, with who ran it and when.

elula db migrations         # name, status, who ran it, when
elula db migrations --json

Migration history also shows in the app's Database tab.

If your framework runs its own migrations at startup (Prisma, Django, Alembic and so on), that works too: they run inside the app with DATABASE_URL.

Run queries

elula db query "SELECT id, email FROM users ORDER BY id DESC LIMIT 10"
elula db query "UPDATE users SET active = true WHERE id = 42"
elula db query "SELECT count(*) FROM orders" --json

In the dashboard, the Databases page lets you browse tables and rows and run queries. Queries and row browsing are recorded in the audit log.

Running queries and migrations needs editor access to the app.

Previews share the database

Pull request previews use the same DATABASE_URL as the live app. A preview that writes data or changes the schema changes your production database.

Deleting

Deleting an app with elula project delete, or Settings → Danger → Delete app, deletes its database too. This can't be undone.