About RedwoodJS apps and databases

(The alternative title would be “how to rebuild an app that already created a persistent database, from scratch”)

RedwoodJS is well recognized and respected by its clever use of generators and by that removing the need for most “pedestrian” steps (creating and managing the database is a good example of such steps).

The problem with this approach (where lot of “stuff” is created without the developer seeing that is going on) are the difficulties related to the decision to restart the application from some point onwards.

Application creation

RedwoodJS tutorial does a great job presenting the sequence of commands needed to create a Redwood application using Redwood CLI, starting with:

yarn create redwood-app ./my-redwood-app

This seemingly simple command created a complex file structure as presented here, implementing the basic implementation of both RedwoodJS sides. In particular, the /api side (aka back-end) contains the db directory with the plumbing for the database and by default that plumbing creates the necessary files for SQlite database.

The summary of this text: it is the RedwoodJS CLI that creates the database plumbing - and does that for the SQLite database only

In order to start a RedwoodJS app that uses some other database (in this text we will pay attention to the PostgreSQL database which is the most likely choice for a “read” (meaning serious) Redwood application. This time, setting the basic database plumbing requires two steps:

In addition to the

yarn create redwood-app ./my-redwood-app

we need to edit the schema.prisma file (created by the first step above) to be: (note the definition of the database provider )

This is the minimum change needed to start using postgres database, provided that you supplied the definition of the “DATABASE_URL” string in your environment (.env) file like


where you need to define the password and database-name to fit your app.

In order to proceed with the app using postgres database development, one would have to create the initial migration

yarn rw prisma migrate dev

in order to proper initial definition of the database plumbing (shown below):


As an example of the migration.sql, consider the “plumbing” for the newest Redwood-Stripe tutorial by Stanislas Duprey, “living” in GitHub - generalui/redwood-stripe: A market place prototype using Redwoodjs and Stripe repository, as migration.sql

Starting this application from scratch

While following the RedwoodJS tutorial (where by following, i mean writing the code and running the generators as described in the tutorial) I tripped every few minutes by either missing a line in the tutorial, problem that would pop-up at the later time and I had no clue what went wrong. The only remedy of course is to delete the code written so far and start again.

As I learned very soon, the app itself is not persisted anywhere - deleting the code makes you perfectly positioned to start again and again, until you manage to write the whole app correctly.

If the app uses the SQLite database - deleting the code is sufficient to start writing the app from the beginning, since the SQLite by default is not persisted. So, my repetitive efforts to create the Redwood Blog application finally yielded success, although that experience led me to create the post Monterey: on reversible rw applications.

The situation is different though because the data created while building the app remains persisted - so you cannot simply delete your code and run the very first step

yarn create redwood-app ./my-app

as it will rewrite the already existing prisma-schema and pretty soon you will be in a pretty deep trouble trying use postgres database with the schema.prisma declaring the intent to use SQLite database situation described with more details here.

At the bare minimum, before starting to write the same code from the beginning, you should use the command:

yarn rw prisma migrate reset

What is your opinion on this post:

  1. quite useful, I learned something new,
  2. so, so, I knew all that, but it refreshed my understanding.
  3. completely irrelevant, why was this even written.
  1. I am a little confused.

I am not really sure what you are trying to do with this post. Is it meant to be a guide? Is it meant to point out the how to switch from MySQL to Postgres? Or is it meant to point out the details that happen when you run a migration?

It is an illustration of the issues encountered when trying to run a relatively complex application again from the beginning. These issues include the persistence of app data kept in the database as well in Stripe (data that Stripe manages in its own database, created with rw app using Stripe API.)

I am sure that all I just wrote is as clear to you as to me. What is missing is the reason for writing this: I will use it in two ways:

1. Tutorial on the Stripe-Redwood application written by Stanislas Duprey

which (tutorial) will be published in RADC blog, as soon as I finish re-checking the application for Stanislas.

2. A background story for the Monterey project

that I hope to catch the attention of a few RW community members, needed to get the project going.I tried to explain this here - apologies for not making a bidirectional link for this explanation :smile_cat:

@KrisCoulson - making more sense now?