How to manage the database for an AI-built app

Decide who operates the database

You can run a database yourself, buy it as a managed service, or use an application platform that includes it. Self-operation leaves patching, monitoring and backup configuration with your team. Railway’s standard templates follow that responsibility model; Render’s paid managed databases include recovery.

AppHaven brings the managed database into the deployment model for AI-built business applications. The setup below uses it, but the persistence and migration checks apply on any host. If your app already has a suitable managed database, compare the benefit of consolidation with the work of moving records.

Start with the data you already have

Before changing the hosting setup, ask your agent where the app writes records today. A local database file, an external service and an in-memory development store need different migration plans. Find uploaded files too: an invoice attachment may live outside the database.

If the app already uses PostgreSQL, AppHaven’s managed database is a compatible starting point. If it uses another engine, test the conversion of its queries, field types and migrations before importing business records. Preserve an export from the old system until the move is verified.

Connect the managed database

services:
  web:
    type: container
    build:
      dockerfile: Dockerfile
    ports:
      - 3000
    env:
      DATABASE_URL: ${service.db.url}
    depends_on:
      - service: db
        condition: healthy

  db:
    type: postgres
    version: "17"

Keep credentials out of routine work

AppHaven supplies the database connection to the running service. Your source code and deployment manifest do not need the password. This removes the need to copy it between a settings page, a local file and an agent conversation.

The running app still has access to its connection details. Code can accidentally print them, and a compromised process may read its environment. Avoid logging environment variables or connection URLs, and check error reports for sensitive values.

Prove that records survive an update

1. 1

   Create a named test record

   In a preview, create an invoice called DATABASE-CHECK and note its amount and status.

2. 2

   Redeploy the same branch

   Change a harmless label and redeploy. Open the invoice again and compare all three fields. This catches apps still writing to an ephemeral development store.

3. 3

   Try the next migration

   Run the proposed schema change on representative test records, including older or incomplete records. Check both the migration log and what the app displays afterwards.

4. 4

   Check production separately

   A preview has its own database. After releasing the production branch, confirm the schema and backup window there too. Test data does not automatically become production data.

Treat a schema change as a change to existing work

Imagine adding a due date to invoices. New invoices may always have one, but old invoices do not. Decide how those records should appear before making the field required. Otherwise a form that works for new invoices may fail whenever someone edits last month’s work.

Keep migrations in Git, review them alongside the code, and avoid dropping data during the same release that stops using it. Test with a realistic number of records when an operation may lock or rewrite a table. An empty preview cannot tell you how that operation behaves on a busy database.

Know what recovery can restore

Plan a restore before an incident

AppHaven captures production backup history automatically. Choose a retention window in Backups, and verify that the displayed window covers what you need. If you might discover an error after a long weekend, plan for that delay.

Restores currently go through AppHaven support. Provide the app, deployment and target time with its timezone. Explain any new records created since that time and whether files must be recovered too. Ask how to validate the recovered data before replacing production. The backup documentation describes the available recovery scope.

Keep a route out

A standard database makes migration possible, but you still need a practical export procedure. AppHaven’s portability documentation describes exporting your application data. Agree on how to obtain an export, protect it, and test it in the destination database.

Do not make an unauthenticated “dump database” endpoint for convenience. An export contains the same sensitive records as production and needs restricted access, secure storage and a deletion policy.