|
| 1 | +--- |
| 2 | +title: Update pgflow |
| 3 | +description: Complete guide to updating pgflow packages and applying new migrations in your Supabase project |
| 4 | +sidebar: |
| 5 | + order: 55 |
| 6 | + badge: |
| 7 | + text: New |
| 8 | + variant: tip |
| 9 | +--- |
| 10 | + |
| 11 | +import { Aside, Steps } from "@astrojs/starlight/components"; |
| 12 | + |
| 13 | +This guide explains how to update pgflow to the latest version, including package updates and database migrations. pgflow updates involve two main components that need to be updated together. |
| 14 | + |
| 15 | +<Aside type="caution" title="Unified Versioning"> |
| 16 | +pgflow uses changesets for version management, which means all packages are versioned together. When you update one pgflow package, all others should be updated to the same version to maintain compatibility. |
| 17 | +</Aside> |
| 18 | + |
| 19 | +## What needs to be updated? |
| 20 | + |
| 21 | +When updating pgflow, you need to update two types of packages: |
| 22 | + |
| 23 | +1. **npm packages** - CLI, core libraries, client, and DSL packages |
| 24 | +2. **JSR package** - The Edge Worker package (published to JSR registry) |
| 25 | +3. **Database migrations** - Schema and function updates |
| 26 | + |
| 27 | +## Update Process |
| 28 | + |
| 29 | +### 1. Update npm packages |
| 30 | + |
| 31 | +Update all pgflow npm packages to the latest version: |
| 32 | + |
| 33 | +```bash frame="none" |
| 34 | +npm update @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl @pgflow/example-flows |
| 35 | +``` |
| 36 | + |
| 37 | +Or if using yarn: |
| 38 | + |
| 39 | +```bash frame="none" |
| 40 | +yarn upgrade @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl @pgflow/example-flows |
| 41 | +``` |
| 42 | + |
| 43 | +Or if using pnpm: |
| 44 | + |
| 45 | +```bash frame="none" |
| 46 | +pnpm update @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl @pgflow/example-flows |
| 47 | +``` |
| 48 | + |
| 49 | +### 2. Update Edge Worker (JSR package) |
| 50 | + |
| 51 | +Update the Edge Worker package in your JSR imports. In your Edge Function files, update the import: |
| 52 | + |
| 53 | +```typescript |
| 54 | +// Before |
| 55 | +import { EdgeWorkerWithPgflow } from "jsr:@pgflow/edge-worker@^0.5.0"; |
| 56 | + |
| 57 | +// After (replace with latest version) |
| 58 | +import { EdgeWorkerWithPgflow } from "jsr:@pgflow/edge-worker@^0.6.0"; |
| 59 | +``` |
| 60 | + |
| 61 | +### 3. Run pgflow install to update migrations |
| 62 | + |
| 63 | +**Always run the install command after updating packages** to check for and apply new database migrations: |
| 64 | + |
| 65 | +```bash frame="none" |
| 66 | +npx pgflow@latest install |
| 67 | +``` |
| 68 | + |
| 69 | +<Aside type="caution" title="Use @latest"> |
| 70 | +Always use `npx pgflow@latest install` to ensure you're running the install command from the latest version. This guarantees you get any new migrations that were added in the update. |
| 71 | +</Aside> |
| 72 | + |
| 73 | +The install command will: |
| 74 | +- Detect any new migrations that need to be installed |
| 75 | +- Copy new migrations with timestamps that place them after your existing migrations |
| 76 | +- Skip migrations that are already installed |
| 77 | +- Show you exactly which migrations will be added before proceeding |
| 78 | + |
| 79 | +### 4. Apply configuration changes (if needed) |
| 80 | + |
| 81 | +If the installer made configuration changes, restart your Supabase instance: |
| 82 | + |
| 83 | +```bash frame="none" |
| 84 | +npx supabase stop |
| 85 | +npx supabase start |
| 86 | +``` |
| 87 | + |
| 88 | +### 5. Apply new migrations |
| 89 | + |
| 90 | +Apply the new migrations to your database: |
| 91 | + |
| 92 | +```bash frame="none" |
| 93 | +npx supabase migrations up |
| 94 | +``` |
| 95 | + |
| 96 | +## Understanding Migration Timestamps |
| 97 | + |
| 98 | +pgflow uses a simple but effective migration system to ensure migrations are applied correctly: |
| 99 | + |
| 100 | +<Aside type="note" title="How Migration Prefixing Works"> |
| 101 | +pgflow uses a simple but effective trick with two timestamps: it keeps the original timestamp in the filename so it can search for already-installed migrations in your folder, while prefixing with a new timestamp that ensures the migration appears as the newest in your Supabase migrations folder. This prevents Supabase from complaining about applying migrations with timestamps older than already-applied ones. |
| 102 | + |
| 103 | +For example, a pgflow migration `20250429164909_pgflow_initial.sql` might be installed as `20250430000010_20250429164909_pgflow_initial.sql` in your project. |
| 104 | +</Aside> |
| 105 | + |
| 106 | +### Migration Naming Convention |
| 107 | + |
| 108 | +pgflow migrations follow this naming pattern when installed: |
| 109 | + |
| 110 | +``` |
| 111 | +[NEW_TIMESTAMP]_[ORIGINAL_TIMESTAMP]_[ORIGINAL_NAME].sql |
| 112 | +``` |
| 113 | + |
| 114 | +Where: |
| 115 | +- `NEW_TIMESTAMP` - Generated timestamp that makes this the newest migration in your folder |
| 116 | +- `ORIGINAL_TIMESTAMP` - The original pgflow migration timestamp |
| 117 | +- `ORIGINAL_NAME` - The original migration file name |
| 118 | + |
| 119 | +The original timestamp allows pgflow to search for and detect which migrations have already been installed, while the new timestamp prefix ensures Supabase can apply the migration without timestamp ordering errors. |
| 120 | + |
| 121 | +## Troubleshooting Updates |
| 122 | + |
| 123 | +### No migrations to install |
| 124 | + |
| 125 | +If `pgflow install` reports "All pgflow migrations are already in place", this means: |
| 126 | +- You already have the latest migrations installed |
| 127 | +- No database schema updates are needed for this version |
| 128 | +- You can proceed with using the updated packages |
| 129 | + |
| 130 | +### Version mismatches |
| 131 | + |
| 132 | +If you encounter issues after updating, verify all packages are on the same version: |
| 133 | + |
| 134 | +```bash frame="none" |
| 135 | +npm list | grep pgflow |
| 136 | +``` |
| 137 | + |
| 138 | +All pgflow packages should show the same version number. |
| 139 | + |
| 140 | +### Migration conflicts |
| 141 | + |
| 142 | +If you encounter migration conflicts: |
| 143 | + |
| 144 | +1. Check if you have custom migrations that conflict with pgflow schema |
| 145 | +2. Review the migration files in `supabase/migrations/` for any obvious conflicts |
| 146 | +3. Consider using the [manual installation approach](/how-to/manual-installation/) for more granular control |
| 147 | + |
| 148 | +## Best Practices |
| 149 | + |
| 150 | +<Aside type="tip" title="Recommended Update Workflow"> |
| 151 | +1. Update packages first |
| 152 | +2. Always run `npx pgflow@latest install` after updating |
| 153 | +3. Review what migrations will be installed before confirming |
| 154 | +4. Test your flows after updating to ensure compatibility |
| 155 | +5. Keep all pgflow packages on the same version |
| 156 | +</Aside> |
| 157 | + |
| 158 | +### When to update |
| 159 | + |
| 160 | +<Aside type="note" title="Pre-1.0 Versioning"> |
| 161 | +Until pgflow reaches 1.0 (production-ready), we use a modified versioning scheme: |
| 162 | +- **Patch releases (0.5.1 → 0.5.2)** - Bug fixes and small backward-compatible features |
| 163 | +- **Minor releases (0.5.0 → 0.6.0)** - Breaking changes and major updates |
| 164 | +- **Major release (0.x.x → 1.x.x)** - Production-ready milestone |
| 165 | +</Aside> |
| 166 | + |
| 167 | +- **Patch releases** - Safe to update immediately, include bug fixes and small backward-compatible improvements |
| 168 | +- **Minor releases** - Review changelog carefully as these may contain breaking changes |
| 169 | +- **Major release to 1.0** - Production-ready milestone, will include comprehensive migration guide |
| 170 | + |
| 171 | +### Staying informed |
| 172 | + |
| 173 | +- Check the [pgflow releases page](https://github.com/pgflow-dev/pgflow/releases) for release notes |
| 174 | +- Review changelog files for detailed changes |
| 175 | +- Test updates in a development environment first |
| 176 | + |
| 177 | +## Development vs Production |
| 178 | + |
| 179 | +### Development Environment |
| 180 | + |
| 181 | +In development, you can update frequently to take advantage of new features and bug fixes: |
| 182 | + |
| 183 | +```bash frame="none" |
| 184 | +npm update @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl |
| 185 | +npx pgflow@latest install -y # Auto-confirm for faster development |
| 186 | +npx supabase migrations up |
| 187 | +``` |
| 188 | + |
| 189 | +### Production Environment |
| 190 | + |
| 191 | +For production updates, follow a more careful approach: |
| 192 | + |
| 193 | +1. Test the update in a staging environment first |
| 194 | +2. Review all new migrations carefully |
| 195 | +3. Plan for any necessary downtime |
| 196 | +4. Keep backups of your database before applying migrations |
| 197 | +5. Monitor your workflows after updating |
| 198 | + |
| 199 | +<Aside type="caution" title="Production Considerations"> |
| 200 | +Always test pgflow updates in a non-production environment first. While pgflow migrations are designed to be safe, any database schema change carries inherent risks in production systems. |
| 201 | +</Aside> |
| 202 | + |
| 203 | +Your pgflow installation is now updated with the latest features, bug fixes, and database schema improvements! |
0 commit comments