tldr; You have huge amount (30+) models/tables in a SDL-type graphql schema (like Fauna)? Use Prisma migrate to generate a postgres database (or update your schema) in Hasura, dump it, clean it, and track it all again in Hasura.
Say you have a (large) schema written in SDL'ish like this
model Post {
id Int @default(autoincrement()) @id
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
title String
content String?
published Boolean @default(false)
author User @relation(fields: [authorId], references: [id])
authorId Int
}
model User { ... }
## 40+ other models!
that you would like to use to generate a new database/schema in Hasura (i.e. the Postgres database). This is how we will do it:
- Use Prisma Migrate to populate the Postgres Database
- Use Hasura metadata "reload" so that Hasura gets back in sync with the postgres database
- Track the tables and relationships in Hasura
- Realize its not exactly what you want so dump it and clean it, and re-track it.
🎉 Voilà!
PS: I am not affiliated to Fauna, Prisma or Hasura.
OK let's do this...
Getting Started
Make sure you have Hasura or Hasura Cloud (its free) project running. In this example we use Hasura Cloud.
1. Bring Prisma into to your project
This is just to use prisma migrate. This is based on this start guide from prisma.
- Create a folder called
prisma_migrateorprisma_stuffanything so that the prisma init later doesn't mess up your project's tooling.
$ mkdir prisma_migrate; cd prisma_migrate
- Install prisma and typescript
$ npm install prisma typescript ts-node @types/node --save-dev
- Add a
tsconfig.jsonin yourprisma_migratefolder
{
"compilerOptions": {
"sourceMap": true,
"outDir": "dist",
"strict": true,
"lib": ["esnext"],
"esModuleInterop": true
}
}
- Initiatilize prisma to get the starter files you need. It will create a
prismadirectory inside yourprisma_generatefolder for you and putschema.prismain there and also.env<-- this is why we created a sub folder, else that would override your own.env
$ npx prisma init
2. Point Prisma to your Postgres database
- Copy the
HASURA_GRAPHQL_DATABASE_URLvariable in your Hasura project settings and paste it in theDATABASE_URLvariable of the.envfile that Prisma generated - Now if you want prisma to generate this into a new schema, just add a
?schema=myapp_testthat will create a new schema in your postgres and Hasura will pick it up later. (This avoids overrides of any existing shcema you have in Hasura), so your.envfile looks something like this (see the end):
DATABASE_URL="postgresql://postgres:XXXXX@potatoes.ce6gsvwmjbvx.us-east-2.rds.amazonaws.com:5432/postgres?schema=potatoes_dev"
Notice that I am using AWS RDS to host my Postgres database, but you could use anything that Hasura supports.
3. Get your SDL schema
OK. We are ready to edit the schema.prisma file by adding our existing schema. This needs to be compatible with Prisma (see prisma's guide for more). So if you have say a Fauna DB SDL schema, make sure to adjust it (still quicker than writing your own SQL migration files in Hasura!)
model Post {
id Int @default(autoincrement()) @id
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
title String
content String?
published Boolean @default(false)
author User @relation(fields: [authorId], references: [id])
authorId Int
}
model Profile {
id Int @default(autoincrement()) @id
bio String?
user User @relation(fields: [userId], references: [id])
userId Int @unique
}
model User {
id Int @default(autoincrement()) @id
email String @unique
name String?
posts Post[]
profile Profile?
}
4. Generate the schema/database in postgres
Now that you have your schema in a happy Prisma SDL format you can run prisma migrate to leverage Prisma's magic in generating Postgres tables.
$ npx prisma migrate dev --name init --preview-feature
That will create the 3 tables in Postgres.
5. Reload your Hasura metadata
You can now reload your schema in Hasura cloud using the cli or the console learn more here.

6. Track all the new tables and relationships
Go to your new schema in the Hasura console track the new tables and relationships. See how here.
Before
After
Track the relationships
🚀 You can now use GraphQL with all the queries and mutations ready!
7. Some gotchas
7.1 Coming from Faunadb
- Missing
idfields: if you are coming from Fauna, you will need to add your ownidfields andcreate_atandupdate_atas Fauna generates the_idand_tsitself. I wrote a little script that parsed the .graphql file and injects it at the top of each model/type, something like this:
lines.push("id Int @id @default(autoincrement())")
lines.push("created_at DateTime @default(now())")
lines.push("updated_at DateTime @updatedAt")
- Changing Long and Date/Time fields: Fauna uses Long, and DateTime. We need to change those, here is a handy script (assuming you are parsing your file and line is each line):
if (line.includes(":")) {
const regex = /([^:]*):\s*(\[?)([^@!\]#/]*)(\]?)!?/m;
const subst = `$1\t\t$3$2$4? `;
line = line.replace(regex, (m:any,g1:string,g2:string,g3:string,g4:string) => {
if(g3.trim() == "Time") {
return `${g1}\t\tDateTime${g2}${g4}? @db.Time() `
} else if(g3.trim() == "Date") {
return `${g1}\t\tDateTime${g2}${g4}? @db.Date `
} else {
g3 = g3.replace("Long","Int");
return `${g1}\t\t${g3}${g2}${g4}? `
}
});
// remove optional list (i.e. []?) not allowed in prisma
line = line.replace("[]?","[]");
return line;
}
7.2 Prisma don't like uuid()
- Prisma's
uuid()function as a@defaultgets ignored by Hasura, so you will need to update the metadata in Hasura to use theirgen_random_uuid()instead. - Once you change the schema with a new function, running the prisma migrate command will cause Prisma Migrate to panic with a
✔ Drift detected: Your database schema is not in sync with your migration history.message, forcing a full reset. So I suggest just using Prisma migrate for an initial port of your schema.
8. Still having issues?
You might find it easier after doing the first prisma migrate to dump the schema to a .sql file and then do some batch editing to change things like id INT to id uuid etc., here is how:
8.1 Dump the schema
Use Postman or curl to POST to the pd_dump of Hasura:
// endpoint: POST https://xxxxxxx.hasura.app/v1alpha1/pg_dump
// body:
{
"opts": ["-O", "-x", "--schema-only", "--schema", "potatoes_dev"],
"clean_output": true
}
8.2 Edit the .sql file
The above will return a dump of the schema, starting with CREATE SCHEMA...
You can edit the file to "replace all" for things like table names and relationships, just keep in mind the following:
- When changing from
INTtoUUIDfor your table id:
- you no longer need the
CREATE SEQUENCE..for those id columns, - make sure to replace the foreign keys for example if the
Authortable has auuidas id, then thePosttable'sauthorIdcolumn needs to change fromauthorId inttoauthorId uuidin itsCREATE TABLE...section
- Prisma uses
AandBfor many-to-many relationships. I'd suggest replacing those with more readable names likePostIdandTagIdfor the_PostTagrelationship table.
-- Ugly and unreadable! --
CREATE TABLE "_PostTag" (
"A" integer NOT NULL,
"B" integer NOT NULL
)
-- Way better --
CREATE TABLE "_PostTag" (
"postId" integer NOT NULL,
"tagId" integer NOT NULL
)
8.3 Delete the schema and run the edited .sql file
You can now delete the schema from within the Hasura console, and run the above sql file from either the console or using any Postgres admin tool like pgAdmin. pgAdmin gives great feedback incase you didn't do a proper clean up or rename of items in our sql file.
8.4 Reload the schema in Hasura
Refresh the Hasura console and notice the schema is there, track the tables and relationsips as described in 6. above



Top comments (0)