Skip to main content
Create database tables and schema.

Overview

Postgres is provisioned by your Terraform ground, in one of three modes chosen in terraform.tfvars: Either way the rendered production configuration arrives complete: DATABASE_URL (pooled, for the services) and DATABASE_URL_DIRECT (for migrations). You never write a connection string by hand.

Steps

1. Run Database Setup

This applies the baseline migration (idempotent, safe to re-run): it enables the vector and pg_stat_statements extensions and creates the complete schema, 26 tables covering:
  • Workflows: workflows, workflow_executions, workflow_snapshots, node_traces
  • Nodes and marketplace: node_definitions, service_definitions, installed_plugins, items, publish_keys
  • Credentials and usage: credentials (encrypted at rest with the master key), token_usage, analytics_events
  • Memory and profiles: memories, user_profiles, goals, raw_messages, knowledge_docs
  • Spatial and content: the dictionary_* family (chunks, ingestion, need states), content_sources
  • Evaluation and security: eval_runs, security_attack_corpus, security_run_results
The migration file itself is the authoritative list: engine/migrations/001_baseline.sql.

2. Verify

BYO Postgres Only

With byo_postgres_url, the ground manages nothing about your database, so the requirements are yours to meet:

Troubleshooting

Relocating Data Between Databases

To move data between database providers (e.g., Timescale β†’ DigitalOcean):
This will:
  1. Install PostgreSQL 17 client tools (if needed)
  2. pg_dump the source database (read-only: source is not modified)
  3. Enable vector and pg_stat_statements extensions on target
  4. pg_restore to the target database
  5. Update /opt/gravity/.env with the new DATABASE_URL
  6. Restart the unoverse service
Note: Timescale-specific errors (continuous_agg, bgw_job) during restore are expected and harmless, all application tables migrate correctly. After relocating, verify with unoverse deploy test.

Next Steps