Every SQL query, Python notebook, and ETL pipeline can run on a schedule — locally on your Mac. No cron server, no Lambda function, no Airflow cluster, no monthly cloud bill.
The data engineering industry has spent the last decade selling complexity. Airflow clusters. Prefect workspaces. Dagster deployments. Step Functions state machines. EventBridge rules. All of this is great if you're running hundreds of interdependent pipelines across a 10-engineer team. For everyone else — solo developers, small data teams, RevOps analysts, indie SaaS founders — it's wildly over-engineered for the problem at hand. Most pipelines are linear: query, transform, deliver. Most schedules are simple: daily, hourly, weekly. Most operations don't have 24/7 SLAs.
A native macOS background process that wakes up at scheduled times, runs your pipeline, logs the result, and goes back to sleep. No external services. No metadata database to manage. No web server to host. No workers to scale. Just a desktop app doing what desktop apps do — running on your computer when you want it to.
Manual (no schedule, manual triggers only). Interval (every N minutes/hours/days). Daily at a specific time. Weekly on specific days at a specific time. Monthly on specific dates. Cron expression for full control. Catch-up on wake (jobs that missed their schedule because the Mac was asleep run on the next wake). These primitives cover roughly 99% of real-world scheduling needs.
Every scheduled job has configurable retry behavior. Set the retry count (default 3), the backoff interval (default exponential starting at 30 seconds), and the failure threshold (immediate fail or fail-after-N). Failed jobs send macOS notifications by default. Configure email alerts or Discord/Slack webhooks for team visibility. The Observatory dashboard shows every failure with full context — what failed, when, why, and how to fix it.
macOS has built-in scheduling via cron (deprecated but functional) and launchd (the modern Apple-recommended approach). Why not use those? Three reasons. First, configuration is painful — cron syntax is famously unfriendly and launchd uses XML plist files. Second, no observability — when a cron job fails at 3 AM, you find out the next morning if you're lucky. Third, no integration with your data tools — cron runs shell scripts, which means you're writing wrapper scripts around your SQL and Python. QueryFlow's scheduler is a first-class part of the data tool you're already using.
GitHub Actions has a free cron scheduler that runs in their cloud. It's a reasonable choice for small workloads — but it adds the friction of writing GitHub Actions workflows in YAML, managing secrets in GitHub, and giving GitHub network access to your databases. For pipelines that should run on your private databases without exposing them to the internet, local scheduling is dramatically simpler and more secure.
Be straightforward. Local scheduling does not work for: pipelines requiring sub-second SLAs (your Mac sleeping breaks this), team-coordinated pipelines where multiple engineers need to manage the same schedule (QueryFlow runs per-Mac), pipelines triggered by external events (no webhook receiver), pipelines requiring multi-region failover. For these cases, cloud orchestration remains the right tool. For everything else — which is most pipelines for most teams — local scheduling on a Mac is the unfussy answer.
Every minute. Practically, scheduling more frequently than every 5 minutes is rarely useful for data pipelines and risks hammering source databases with redundant queries. The most common intervals are every 15 minutes, hourly, every 4 hours, and daily.
Yes. The scheduler runs jobs concurrently by default. If two jobs fire at the same time, both start in parallel. For jobs that must run sequentially (e.g., load fact table, then refresh aggregates), configure pipeline dependencies in the schedule settings.
By default, the scheduler skips the new run with a 'previous instance still running' log entry. You can configure overlap behavior per job: skip (default), queue (run after current finishes), or cancel-current-and-restart. Skip is the safe default for most pipelines.
Yes, but minimally — typically 30-50MB of RAM and effectively zero CPU. The scheduler sits in a sleep state between trigger checks. macOS App Nap further reduces resource usage when QueryFlow is in the background. For a 24/7 setup, the system overhead is negligible.
Indirectly — through whatever notification channel you configure. Set up email alerts on job failure, or webhook alerts to Discord or Slack, and those reach your phone through their respective apps. There is no dedicated QueryFlow mobile companion app yet.
14-day free trial. Schedule your first pipeline this morning, and tomorrow it runs on its own.