@@ -2,56 +2,55 @@
22
33[](https://github.com/fabianlindfors/reshape/actions/workflows/test.yaml) [](https://github.com/fabianlindfors/reshape/releases)
44
5−> Also check out [ReshapeDB](https://reshapedb.com), a new database built from the ground up to make zero-downtime schema and data migrations as simple and safe as possible. If you'd like to chat about it, please [reach out](contact@reshapedb.com)!
6−
75Reshape is an easy-to-use, zero-downtime schema migration tool for Postgres. It automatically handles complex migrations that would normally require downtime or manual multi-step changes. During a migration, Reshape ensures both the old and new schema are available at the same time, allowing you to gradually roll out your application. It will also perform all changes without excessive locking, avoiding downtime caused by blocking other queries. For a more thorough introduction to Reshape, check out the [introductory blog post](https://fabianlindfors.se/blog/schema-migrations-in-postgres-using-reshape/).
86
97Designed for Postgres 12 and later.
108
9+*Note: Reshape is **experimental** and should not be used in production. It can (and probably will) break your application.*
10+
1111- [How it works](#how-it-works)
1212- [Getting started](#getting-started)
13− - [Installation](#installation)
14− - [Creating your first migration](#creating-your-first-migration)
15− - [Preparing your application](#preparing-your-application)
16− - [Running your migration](#running-your-migration)
17− - [Using during development](#using-during-development)
13+ - [Installation](#installation)
14+ - [Creating your first migration](#creating-your-first-migration)
15+ - [Preparing your application](#preparing-your-application)
16+ - [Running your migration](#running-your-migration)
17+ - [Using during development](#using-during-development)
1818- [Writing migrations](#writing-migrations)
19− - [Basics](#basics)
20− - [Tables](#tables)
21− - [Create table](#create-table)
22− - [Rename table](#rename-table)
23− - [Remove table](#remove-table)
24− - [Add foreign key](#add-foreign-key)
25− - [Remove foreign key](#remove-foreign-key)
26− - [Columns](#columns)
27− - [Add column](#add-column)
28− - [Alter column](#alter-column)
29− - [Remove column](#remove-column)
30− - [Indices](#indices)
31− - [Add index](#add-index)
32− - [Remove index](#remove-index)
33− - [Enums](#enums)
34− - [Create enum](#create-enum)
35− - [Remove enum](#remove-enum)
36− - [Custom](#custom)
37− - [Complex changes across tables](#complex-changes-across-tables)
19+ - [Basics](#basics)
20+ - [Tables](#tables)
21+ - [Create table](#create-table)
22+ - [Rename table](#rename-table)
23+ - [Remove table](#remove-table)
24+ - [Add foreign key](#add-foreign-key)
25+ - [Remove foreign key](#remove-foreign-key)
26+ - [Columns](#columns)
27+ - [Add column](#add-column)
28+ - [Alter column](#alter-column)
29+ - [Remove column](#remove-column)
30+ - [Indices](#indices)
31+ - [Add index](#add-index)
32+ - [Remove index](#remove-index)
33+ - [Enums](#enums)
34+ - [Create enum](#create-enum)
35+ - [Remove enum](#remove-enum)
3836- [Commands and options](#commands-and-options)
39− - [`reshape migration start`](#reshape-migration-start)
40− - [`reshape migration complete`](#reshape-migration-complete)
41− - [`reshape migration abort`](#reshape-migration-abort)
42− - [`reshape schema-query`](#reshape-schema-query)
43− - [Connection options](#connection-options)
37+ - [`reshape migrate`](#reshape-migrate)
38+ - [`reshape complete`](#reshape-complete)
39+ - [`reshape abort`](#reshape-abort)
40+ - [`reshape generate-schema-query`](#reshape-generate-schema-query)
41+ - [Connection options](#connection-options)
4442- [License](#license)
4543
44+
4645## How it works
4746
4847Reshape works by creating views that encapsulate the underlying tables, which your application will interact with. During a migration, Reshape will automatically create a new set of views and set up triggers to translate inserts and updates between the old and new schema. This means that every deployment is a three-phase process:
4948
50−1. **Start migration** (`reshape migration start`): Sets up views and triggers to ensure both the new and old schema are usable at the same time.
49+1. **Start migration** (`reshape migrate`): Sets up views and triggers to ensure both the new and old schema are usable at the same time.
51502. **Roll out application**: Your application can be gradually rolled out without downtime. The existing deployment will continue using the old schema whilst the new deployment uses the new schema.
52−3. **Complete migration** (`reshape migration complete`): Removes the old schema and any intermediate data and triggers.
51+3. **Complete migration** (`reshape complete`): Removes the old schema and any intermediate data and triggers.
5352
54−If the application deployment fails, you should run `reshape migration abort` which will roll back any changes made by `reshape migration start` without losing data.
53+If the application deployment fails, you should run `reshape abort` which will roll back any changes made by `reshape migrate` without losing data.
5554
5655## Getting started
5756
@@ -71,10 +70,10 @@ cargo install reshape
7170
7271#### Docker
7372
74−Reshape is available as a Docker image on [Docker Hub](https://hub.docker.com/repository/docker/fabianlindfors/reshape).
73+Reshape is available as a Docker image on [Docker Hub](https://hub.docker.com/repository/docker/fabianlindfors/reshape).
7574
7675```shell
77−docker run -v $(pwd):/usr/share/app fabianlindfors/reshape reshape migration start
76+docker run -v $(pwd):/usr/share/app fabianlindfors/reshape reshape migrate
7877```
7978
8079### Creating your first migration
@@ -103,14 +102,9 @@ This is the equivalent of running `CREATE TABLE users (id INTEGER GENERATED ALWA
103102
104103### Preparing your application
105104
106−Reshape relies on your application using a specific schema. When establishing the connection to Postgres in your application, you need to run a query to select the most recent schema. The simplest way to do this is to use one of the helper libraries:
107−
108−- [Rust](https://github.com/fabianlindfors/reshape-helper)
109−- [Ruby (and Rails)](https://github.com/fabianlindfors/reshape-ruby)
110−- [Python (and Django)](https://github.com/fabianlindfors/reshape-python)
111−- [Go](https://github.com/leourbina/reshape-helper)
105+Reshape relies on your application using a specific schema. When establishing the connection to Postgres in your application, you need to run a query to select the most recent schema. This query can be generated using: `reshape generate-schema-query`.
112106
113−If your application is not using one of the languages with an available helper library, you can instead generate the query with the command: `reshape schema-query`. To pass it along to your application, you can for example use an environment variable in your run script: `RESHAPE_SCHEMA_QUERY=$(reshape schema-query)`. Then in your application:
107+To pass it along to your application, you can for example use an environment variable in your run script: `RESHAPE_SCHEMA_QUERY=$(reshape generate-schema-query)`. Then in your application:
114108
115109```python
116110# Example for Python
@@ -118,21 +112,23 @@ reshape_schema_query = os.getenv("RESHAPE_SCHEMA_QUERY")
118112db.execute(reshape_schema_query)
119113```
120114
115+If your application is written in Rust, you might prefer the [Rust helper library](https://github.com/fabianlindfors/reshape-helper) which embeds the query directly in your application with a macro.
116+
121117### Running your migration
122118
123119To create your new `users` table, run:
124120
125121```bash
126−reshape migration start --complete
122+reshape migrate --complete
127123```
128124
129−We use the `--complete` flag to automatically complete the migration. During a production deployment, you should first run `reshape migration start` followed by `reshape migration complete` once your application has been fully rolled out.
125+We use the `--complete` flag to automatically complete the migration. During a production deployment, you should first run `reshape migrate` followed by `reshape complete` once your application has been fully rolled out.
130126
131127If nothing else is specified, Reshape will try to connect to a Postgres database running on `localhost` using `postgres` as both username and password. See [Connection options](#connection-options) for details on how to change the connection settings.
132128
133129### Using during development
134130
135−When adding new migrations during development, we recommend running `reshape migration start` but skipping `reshape migration complete`. This way, the new migrations can be iterated on by updating the migration file and running `reshape migration abort` followed by `reshape migration start`.
131+When adding new migrations during development, we recommend running `reshape migrate` but skipping `reshape complete`. This way, the new migrations can be iterated on by updating the migration file and running `reshape abort` followed by `reshape migrate`.
136132
137133## Writing migrations
138134
@@ -167,9 +163,9 @@ Every action has a `type`. The supported types are detailed below.
167163
168164#### Create table
169165
170−The `create_table` action will create a new table with the specified columns, indices and constraints. You can optionally provide an `up` option to backfill values from an existing table.
166+The `create_table` action will create a new table with the specified columns, indices and constraints.
171167
172−_Example: create a `customers` table with a few columns and a primary key_
168+*Example: create a `customers` table with a few columns and a primary key*
173169
174170```toml
175171[[actions]]
@@ -187,13 +183,13 @@ primary_key = ["id"]
187183 type = "TEXT"
188184
189185 # Columns default to nullable
190− nullable = false
186+ nullable = false
191187
192188 # default can be any valid SQL value, in this case a string literal
193− default = "'PLACEHOLDER'"
189+ default = "'PLACEHOLDER'"
194190```
195191
196−_Example: create `users` and `items` tables with a foreign key between them_
192+*Example: create `users` and `items` tables with a foreign key between them*
197193
198194```toml
199195[[actions]]
@@ -226,34 +222,11 @@ primary_key = ["id"]
226222 referenced_columns = ["id"]
227223```
228224
229−_Example: create `profiles` table based on existing `users` table_
230−
231−```toml
232−[[actions]]
233−type = "create_table"
234−name = "profiles"
235−primary_key = ["user_id"]
236−
237− [[actions.columns]]
238− name = "user_id"
239− type = "INTEGER"
240−
241− [[actions.columns]]
242− name = "user_email"
243− type = "TEXT"
244−
245− # Backfill from `users` table and copy `users.email` to `user_email` column
246− # This will perform an upsert based on the primary key to avoid duplicate rows
247− [actions.up]
248− table = "users"
249− values = { user_id = "id", user_email = "email" }
250−```
251−
252225#### Rename table
253226
254227The `rename_table` action will change the name of an existing table.
255228
256−_Example: change name of `users` table to `customers`_
229+*Example: change name of `users` table to `customers`*
257230
258231```toml
259232[[actions]]
@@ -266,7 +239,7 @@ new_name = "customers"
266239
267240The `remove_table` action will remove an existing table.
268241
269−_Example: remove `users` table_
242+*Example: remove `users` table*
270243
271244```toml
272245[[actions]]
@@ -278,7 +251,7 @@ table = "users"
278251
279252The `add_foreign_key` action will add a foreign key between two existing tables. The migration will fail if the existing column values aren't valid references.
280253
281−_Example: create foreign key from `items` to `users` table_
254+*Example: create foreign key from `items` to `users` table*
282255
283256```toml
284257[[actions]]
@@ -295,7 +268,7 @@ table = "items"
295268
296269The `remove_foreign_key` action will remove an existing foreign key. The foreign key will only be removed once the migration is completed, which means that your new application must continue to adhere to the foreign key constraint.
297270
298−_Example: remove foreign key `items_user_id_fkey` from `users` table_
271+*Example: remove foreign key `items_user_id_fkey` from `users` table*
299272
300273```toml
301274[[actions]]
@@ -308,9 +281,9 @@ foreign_key = "items_user_id_fkey"
308281
309282#### Add column
310283
311−The `add_column` action will add a new column to an existing table. You can optionally provide an `up` setting. This should be an SQL expression which will be run for all existing rows to backfill the new column. `up` may also reference another table to perform cross-table migrations (see ["Complex changes across tables"](#complex-changes-across-tables)).
284+The `add_column` action will add a new column to an existing table. You can optionally provide an `up` setting. This should be an SQL expression which will be run for all existing rows to backfill the new column.
312285
313−_Example: add a new column `reference` to table `products`_
286+*Example: add a new column `reference` to table `products`*
314287
315288```toml
316289[[actions]]
@@ -324,7 +297,7 @@ table = "products"
324297 default = "10"
325298```
326299
327−_Example: replace an existing `name` column with two new columns, `first_name` and `last_name`_
300+*Example: replace an existing `name` column with two new columns, `first_name` and `last_name`*
328301
329302```toml
330303[[actions]]
@@ -360,7 +333,7 @@ column = "name"
360333down = "first_name || ' ' || last_name"
361334```
362335
363−_Example: extract nested value from unstructured JSON `data` column to new `name` column_
336+*Example: extract nested value from unstructured JSON `data` column to new `name` column*
364337
365338```toml
366339[[actions]]
@@ -375,25 +348,6 @@ up = "data['path']['to']['value'] #>> '{}'"
375348 type = "TEXT"
376349```
377350
378−_Example: duplicate `email` column from `users` to `profiles` table_
379−
380−```toml
381−# `profiles` has `user_id` column which maps to `users.id`
382−[[actions]]
383−type = "add_column"
384−table = "profiles"
385−
386− [actions.column]
387− name = "email"
388− type = "TEXT"
389− nullable = false
390−
391− # When `users` is updated in the old schema, we write the email value to `profiles`
392− [actions.up]
393− table = "users"
394− value = "email"
395− where = "user_id = id"
396−```
397351
398352#### Alter column
399353
@@ -401,7 +355,7 @@ The `alter_column` action enables many different changes to an existing column,
401355
402356When performing more complex changes than a rename, `up` and `down` should be provided. These should be SQL expressions which determine how to transform between the new and old version of the column. Inside those expressions, you can reference the current column value by the column name.
403357
404−_Example: rename `last_name` column on `users` table to `family_name`_
358+*Example: rename `last_name` column on `users` table to `family_name`*
405359
406360```toml
407361[[actions]]
@@ -413,7 +367,7 @@ column = "last_name"
413367 name = "family_name"
414368```
415369
416−_Example: change the type of `reference` column from `INTEGER` to `TEXT`_
370+*Example: change the type of `reference` column from `INTEGER` to `TEXT`*
417371
418372```toml
419373[[actions]]
@@ -428,7 +382,7 @@ down = "CAST(reference AS INTEGER)" # Converts from text value to integer
428382 type = "TEXT" # Previous type was 'INTEGER'
429383```
430384
431−_Example: increment all values of an `index` column by one_
385+*Example: increment all values of an `index` column by one*
432386
433387```toml
434388[[actions]]
@@ -443,7 +397,7 @@ down = "index - 1" # Decrement to revert for old schema
443397 name = "index"
444398```
445399
446−_Example: make `name` column not nullable_
400+*Example: make `name` column not nullable*
447401
448402```toml
449403[[actions]]
@@ -458,7 +412,7 @@ up = "COALESCE(name, 'N/A')"
458412 nullable = false
459413```
460414
461−_Example: change default value of `created_at` column to current time_
415+*Example: change default value of `created_at` column to current time*
462416
463417```toml
464418[[actions]]
@@ -472,11 +426,11 @@ column = "created_at"
472426
473427#### Remove column
474428
475−The `remove_column` action will remove an existing column from a table. You can optionally provide a `down` setting. This should be an SQL expression which will be used to determine values for the old schema when inserting or updating rows using the new schema. `down` may also reference another table to perform cross-table migrations (see ["Complex changes across tables"](#complex-changes-across-tables)) . The `down` setting must be provided when the removed column is `NOT NULL` or doesn't have a default value.
429+The `remove_column` action will remove an existing column from a table. You can optionally provide a `down` setting. This should be an SQL expression which will be used to determine values for the old schema when inserting or updating rows using the new schema. The `down` setting must be provided when the removed column is `NOT NULL` or doesn't have a default value.
476430
477431Any indices that cover the column will be removed.
478432
479−_Example: remove column `name` from table `users`_
433+*Example: remove column `name` from table `users`*
480434
481435```toml
482436[[actions]]
@@ -488,34 +442,18 @@ column = "name"
488442down = "'N/A'"
489443```
490444
491−_Example: remove `email` column from `users` table and use column from `profiles` table instead_
492−
493−```toml
494−[[actions]]
495−type = "remove_column"
496−table = "users"
497−column = "email"
498−
499− # Our application will use the `profiles.email` column instead
500− # For backwards compatibility, we will write back to the removed `email` column whenever `profiles` is changed
501− [actions.down]
502− table = "profiles"
503− value = "profiles.email"
504− where = "users.id = profiles.user_id"
505−```
506−
507445### Indices
508446
509447#### Add index
510448
511449The `add_index` action will add a new index to an existing table.
512450
513−_Example: create a `users` table with a unique index on the `name` column_
451+*Example: create a `users` table with a unique index on the `name` column*
514452
515453```toml
516454[[actions]]
517455type = "create_table"
518−name = "users"
456+table = "users"
519457primary_key = "id"
520458
521459 [[actions.columns]]
@@ -539,7 +477,7 @@ table = "users"
539477 unique = true
540478```
541479
542−_Example: add GIN index to `data` column on `products` table_
480+*Example: add GIN index to `data` column on `products` table*
543481
544482```toml
545483[[actions]]
@@ -558,7 +496,7 @@ table = "products"
558496
559497The `remove_index` action will remove an existing index. The index won't actually be removed until the migration is completed.
560498
561−_Example: remove the `name_idx` index_
499+*Example: remove the `name_idx` index*
562500
563501```toml
564502[[actions]]
@@ -572,7 +510,7 @@ index = "name_idx"
572510
573511The `create_enum` action will create a new [enum type](https://www.postgresql.org/docs/current/datatype-enum.html) with the specified values.
574512
575−_Example: add a new `mood` enum type with three possible values_
513+*Example: add a new `mood` enum type with three possible values*
576514
577515```toml
578516[[actions]]
@@ -585,7 +523,7 @@ values = ["happy", "ok", "sad"]
585523
586524The `remove_enum` action will remove an existing [enum type](https://www.postgresql.org/docs/current/datatype-enum.html). Make sure all usages of the enum has been removed before running the migration. The enum will only be removed once the migration is completed.
587525
588−_Example: remove the `mood` enum type_
526+*Example: remove the `mood` enum type*
589527
590528```toml
591529[[actions]]
@@ -593,162 +531,47 @@ type = "remove_enum"
593531enum = "mood"
594532```
595533
596−### Custom
597−
598−The `custom` action lets you create a migration which runs custom SQL. It should be used with great care as it provides no guarantees of zero-downtime and will simply run whatever SQL is provided. Use other actions whenever possible as they are explicitly designed for zero downtime.
599−
600−There are three optional settings available which all accept SQL queries. All queries need to be idempotent, for example by using `IF NOT EXISTS` wherever available.
601−
602−- `start`: run when a migration is started using `reshape migration start`
603−- `complete`: run when a migration is completed using `reshape migration complete`
604−- `abort`: run when a migration is aborted using `reshape migration abort`
605−
606−_Example: enable PostGIS and pg_stat_statements extensions_
607−
608−```toml
609−[[actions]]
610−type = "custom"
611−
612−start = """
613− CREATE EXTENSION IF NOT EXISTS postgis;
614− CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
615−"""
616−
617−abort = """
618− DROP EXTENSION IF EXISTS postgis;
619− DROP EXTENSION IF EXISTS pg_stat_statements;
620−"""
621−```
622−
623−### Complex changes across tables
624−
625−The `up` and `down` options available when creating tables, adding columns and removing columns can also perform more complex changes that span tables.
626−
627−_Example: move `email` column from `users` to `profiles` table_
628−
629−```toml
630−[[actions]]
631−type = "add_column"
632−table = "profiles"
633−
634− [actions.column]
635− name = "email"
636− type = "TEXT"
637− nullable = false
638−
639− # When `users` is updated in the old schema, we write the email value to `profiles`
640− [actions.up]
641− table = "users"
642− value = "users.email"
643− where = "profiles.user_id = users.id"
644−
645−[[actions]]
646−type = "remove_column"
647−table = "users"
648−column = "email"
649−
650− # When `profiles` is changed in the new schema, we write the email address back to the removed column
651− [actions.down]
652− table = "profiles"
653− value = "profiles.email"
654− where = "users.id = profiles.user_id"
655−```
656−
657−_Example: turn a 1:N relationship between `users` and `accounts` into N:M and change the format of the associated `role`_
658−
659−```toml
660−# Add `user_account_connections` as a junction table
661−[[actions]]
662−type = "create_table"
663−name = "user_account_connections"
664−primary_key = ["account_id", "user_id"]
665−
666− [[actions.columns]]
667− name = "account_id"
668− type = "INTEGER"
669−
670− [[actions.columns]]
671− name = "user_id"
672− type = "INTEGER"
673−
674− # `role` is currently stored directly on the `users` table but is part of the relationship
675− [[actions.columns]]
676− name = "role"
677− type = "TEXT"
678− nullable = false
679−
680− # Backfill the new table from `users` and uppercase the `role`
681− [actions.up]
682− table = "users"
683− values = { user_id = "id", account_id = "account_id", role = "UPPER(account_role)" }
684− where = "user_account_connections.user_id = users.id"
685−
686−[[actions]]
687−type = "remove_column"
688−table = "users"
689−column = "account_id"
690−
691− # When `user_account_connections` is updated, we write the `account_id` back to `users`
692− [actions.down]
693− table = "user_account_connections"
694− value = "user_account_connections.account_id"
695− where = "users.id = user_account_connections.user_id"
696−
697−[[actions]]
698−type = "remove_column"
699−table = "users"
700−column = "account_role"
701−
702− # When `user_account_connections` is updated, we write the lowercase role back to `users`
703− [actions.down]
704− table = "user_account_connections"
705− value = "LOWER(user_account_connections.role)"
706− where = "users.id = user_account_connections.user_id"
707−```
708−
709534## Commands and options
710535
711−### `reshape migration start`
536+### `reshape migrate`
712537
713−Starts a new migration, applying all migrations under `migrations/` that haven't yet been applied. After the command has completed, both the old and new schema will be usable at the same time. When you have rolled out the new version of your application which uses the new schema, you should run `reshape migration complete`.
538+Starts a new migration, applying all migrations under `migrations/` that haven't yet been applied. After the command has completed, both the old and new schema will be usable at the same time. When you have rolled out the new version of your application which uses the new schema, you should run `reshape complete`.
714539
715540#### Options
716541
717−_See also [Connection options](#connection-options)_
542+*See also [Connection options](#connection-options)*
718543
719−| Option | Default | Description |
720−| ------------------ | ------------- | --------------------------------------------------------------------------------------------------------------- |
721−| `--complete`, `-c` | `false` | Automatically complete migration after applying it. |
722−| `--dirs` | `migrations/` | Directories to search for migration files. Multiple directories can be specified using `--dirs dir1 dir2 dir3`. |
544+| Option | Default | Description |
545+| ------ | ------- | ----------- |
546+| `--complete`, `-c` | `false` | Automatically complete migration after applying it. |
547+| `--dirs` | `migrations/` | Directories to search for migration files. Multiple directories can be specified using `--dirs dir1 dir2 dir3`. |
723548
724−### `reshape migration complete`
549+### `reshape complete`
725550
726−Completes migrations previously started with `reshape migration complete`.
551+Completes migrations previously started with `reshape complete`.
727552
728553#### Options
729554
730555See [Connection options](#connection-options)
731556
732−### `reshape migration abort`
557+### `reshape abort`
733558
734−Aborts any migrations which haven't yet been completed.
559+Aborts any migrations which haven't yet been completed.
735560
736561#### Options
737562
738563See [Connection options](#connection-options)
739564
740−### `reshape schema-query`
565+### `reshape generate-schema-query`
741566
742567Generates the SQL query you need to run in your application before using the database. This command does not require a database connection. Instead it will generate the query based on the latest migration in the `migrations/` directory (or the directories specified by `--dirs`).
743568
744−If your application is written in Rust, we recommend using the [Rust helper library](https://github.com/fabianlindfors/reshape-helper/) instead.
745−
746569The query should look something like `SET search_path TO migration_1_initial_migration`.
747570
748571#### Options
749572
750−| Option | Default | Description |
751−| -------- | ------------- | --------------------------------------------------------------------------------------------------------------- |
573+| Option | Default | Description |
574+| ------ | ------- | ----------- |
752575| `--dirs` | `migrations/` | Directories to search for migration files. Multiple directories can be specified using `--dirs dir1 dir2 dir3`. |
753576
754577### Connection options
@@ -757,14 +580,14 @@ The options below can be used with all commands that communicate with Postgres.
757580
758581All options can also be set using environment variables instead of flags. If a `.env` file exists, then variables will be automatically loaded from there.
759582
760−| Option | Default | Environment variable | Description |
761−| ------------ | ----------- | -------------------- | ------------------------------------------- |
762−| `--url` | | `DB_URL` | URL to your Postgres database |
763−| `--host` | `localhost` | `DB_HOST` | Hostname to use when connecting to Postgres |
764−| `--port` | `5432` | `DB_PORT` | Port which Postgres is listening on |
765−| `--database` | `postgres` | `DB_NAME` | Database name |
766−| `--username` | `postgres` | `DB_USERNAME` | Postgres username |
767−| `--password` | `postgres` | `DB_PASSWORD` | Postgres password |
583+| Option | Default | Environment variable | Description |
584+| ------ | ------- | -------------------- | ----------- |
585+| `--url` | | `DB_URL` | URL to your Postgres database |
586+| `--host` | `localhost` | `DB_HOST` | Hostname to use when connecting to Postgres |
587+| `--port` | `5432` | `DB_PORT` | Port which Postgres is listening on |
588+| `--database` | `postgres` | `DB_NAME` | Database name |
589+| `--username` | `postgres` | `DB_USERNAME` | Postgres username |
590+| `--password` | `postgres` | `DB_PASSWORD` | Postgres password |
768591
769592## License
770593