Moped Documentation
  • Welcome 👋
  • User Guides
    • Getting started
    • Map a project
  • Product Management
    • User communication
    • User management
    • User analytics
    • Local testing
    • Release process
    • Patch release process
    • MUI X Pro License
    • Integrations
      • Dataset documentation
      • ArcGIS Online
      • eCapris
      • Power BI
    • Features
  • Dev Guides
    • DB Docs & Data dictionary
    • Database backup policy
    • Moped Read Replica
    • How-to's
      • How do I start the Hasura cluster locally?
      • How do I launch the Hasura Console?
      • How do I get a JWT token?
      • How to ping the GraphQL API
      • How to ping the REST API
      • How do I connect a database with Postgres GUIs?
      • How do I connect to the RDS instance?
      • How to load production data into a local instance
      • How do I update seed data?
    • Hasura
      • Hasura Roles
      • Hasura Migrations
        • Getting Started
        • Installing the Hasura CLI
        • Configuration Files
        • Hasura Migration Principles
        • The Migration file format
        • Development
        • Hasura Seed Data
        • Running the Hasura Cluster Locally (video)
        • Create a migration: Exercise 1 (video)
        • Create a migration: Exercise 2 (video)
        • Latest hasura-cluster features
    • User Management
    • Authentication
      • Authentication Architecture
      • DynamoDB & Cognito
      • Secrets Manager & Cognito
      • Hasura & Cognito
      • React & Cognito
      • Flask API & Cognito
      • Single Sign-On with CTM
    • Code organization
    • API
      • Configuration Files
      • Testing
      • User Management API
    • Maps and geospatial data
      • Access tokens and API keys
      • Map libraries
      • Map data
      • Map styles
      • Map layers and basemaps
      • React patterns
      • V1 Archive
        • Map libraries
        • Map data
        • Map custom hooks
        • Map styles
        • Map layers and basemaps
    • UI access control
    • Design system
      • Branding
      • Component styles
      • Text content
    • Activity Log
      • Architecture
      • GitHub Actions and Deployment of Updates
      • Hasura Event Logs and Truncate Cron Job
      • Authentication
  • See also
  • Get Moped support, report a bug, or request an enhancement
  • Data & Technology Services
  • Github repository
Powered by GitBook
On this page

Was this helpful?

  1. Dev Guides
  2. Hasura
  3. Hasura Migrations

The Migration file format

PreviousHasura Migration PrinciplesNextDevelopment

Last updated 4 years ago

Was this helpful?

These are the principles:

  1. In short, migration files are pure SQL files.

  2. Each migration file has the following format:

    <version>_<name>.{up|down}.sql

    A version which is the Unix timestamp in nanoseconds when the file was created is the first part. Followed by a name which is either manually added or auto-generated by the console. The next part indicates what step this is. If it is up, it means that this is the forward step, e.g. creating a table. The down indicates that it is the corresponding rollback step.

  3. A migration SQL file can contain SQL statements which are executed on the apply step of the migration.

  4. The UP file contains any sql statements to be run by the apply command, you can think of this as going UP one version. The SQL can create, update, drop tables, rename resources, etc. Whatever is necessary to accomplish the NEXT version.

  5. The DOWN file contains any SQL statements to roll back this version. It is a bit more complex because it has to change back any modifications made by UP.

For more details on the format of these files, refer to the

Hasura Migrations - The Metadata directory

The following files will be generated in the metadata/ directory of your project.

  • version.yaml: Contains the metadata version of the server

  • tables.yaml: Contains the metadata related to tables

  • remote_schemas.yaml: Contains the metadata related to remote schemas

  • functions.yaml: Contains the metadata related to custom functions

  • allow_list.yaml: Contains the metadata related to allow lists

  • actions.yaml: Contains the metadata related to actions

  • actions.graphql: Contains all the action definition and custom type definitions

For more details on the format of these files, refer to the

Migration file format documentation
Metadata directory format documentation