Performance
Core operations are optimized with batching, proper indexing, and declarative SQL. However, large-scale workloads may reveal additional optimization opportunities. Start with your expected workload and scale as needed.
pgflow is in public beta and being used in production by early adopters. Core functionality is stable and reliable.
Performance
Core operations are optimized with batching, proper indexing, and declarative SQL. However, large-scale workloads may reveal additional optimization opportunities. Start with your expected workload and scale as needed.
Worker Management
Edge Functions have platform execution time limits. For production reliability, set up a pg_cron job to automatically restart workers when needed. See deployment guide for the simple 2-minute setup.
Fair Processing
Fair processing across flows is not currently implemented. A flow with many tasks (especially map steps processing large arrays) can fill the queue ahead of other flows. This is more noticeable with the introduction of map steps in 0.7.0. For multi-tenant or multi-flow scenarios where fairness is important, join Discord to discuss approaches and workarounds.
Permissions
pgflow ships with zero built-in permissions or access controls. Database permissions must be manually configured when using the TypeScript Client or Supabase RPC from client applications. In a future release, pgflow will support custom start functions for the TypeScript Client, enabling authorization logic at the database level and supporting multi-tenant scenarios.
During beta, breaking changes may be introduced for critical fixes or significant improvements. All changes are documented in release notes with migration guides. See updating pgflow for the update process.
Connect on Discord