Stop deploying Python ETL scripts to Lambda. Stop debugging CloudWatch logs. Stop maintaining IAM roles. Run your data pipelines on your Mac with a real UI.
AWS Lambda is the default answer for 'how do I run this Python script on a schedule?' Combined with EventBridge (formerly CloudWatch Events), it's the canonical AWS pattern for serverless data jobs. The setup is well-documented, the cost per invocation is tiny, and it scales infinitely. For one or two scripts, Lambda is genuinely good.
After three or four Lambda functions, the operational tax becomes obvious. Each function needs: a deployment process (zip the code, push to Lambda, manage versions), IAM permissions (which often expand over time into complex policy documents), environment variables for secrets (or Secrets Manager integration), CloudWatch Logs for debugging (which costs real money at scale), an EventBridge rule for scheduling, and a layer of glue code that turns Python data work into Lambda-compatible handlers.
Updating a Lambda function takes an actual deployment. You change Python code locally, zip it up (don't forget the dependencies), upload to Lambda or push through SAM/CDK/Serverless Framework, wait for the deploy, then test in CloudWatch. For data pipelines that change frequently — adding a new column, fixing a SOQL query, adjusting a transformation — this deployment overhead multiplies. Teams routinely report that 30-50% of their time on Lambda-based ETL is the deployment-and-debug loop, not the actual data work.
In QueryFlow, you write your pipeline once and edit it interactively. Change the SQL query, click Run, see the new result. Adjust the field mapping, click Run, see how it lands in the destination. Modify the Python cell, click Run, see the output. When everything looks right, click Schedule and walk away. There's no deployment step because there's no separate runtime to deploy to — the code runs in QueryFlow on your Mac.
Lambda's CloudWatch Logs are functional but punishing — you're parsing JSON log entries through a web UI optimized for search-by-time-window. QueryFlow's Observatory dashboard shows every pipeline run with rich context: the query that ran, the rows processed, the errors with full Salesforce or Postgres error messages, the duration, the source row data for failures. Click any run, see what happened. No CloudWatch query syntax to learn.
Lambda functions accessing Salesforce, Snowflake, or third-party APIs need their credentials somewhere. The right answer is AWS Secrets Manager ($0.40/secret/month plus API calls) with IAM roles granting Lambda access. The implementation is boilerplate code that every Lambda team writes the same way. QueryFlow uses macOS Keychain — credentials are encrypted at rest using your Mac's Secure Enclave, accessible only to authorized applications, with no quota or per-secret cost.
Be straightforward: Lambda is still better for event-driven workflows (responding to S3 uploads, SNS messages, API Gateway requests), pipelines that need to scale to handle traffic spikes (Lambda's auto-scaling is genuinely useful), workflows that must run when no one is at a Mac (Lambda's always-on availability matters), and team-managed pipelines where centralized deployment and IAM are required. QueryFlow targets the scheduled batch use case — daily/hourly/weekly jobs that don't need infinite scale or event triggering.
Lambda is 'pay per invocation,' which is genuinely cheap for low-volume workloads — a small team might pay $5-$20/month in Lambda costs. The hidden costs are CloudWatch Logs ($100-$500/month for active ETL teams), Secrets Manager ($10-$50/month), and engineering time spent on deployments and IAM. QueryFlow is $299.99/year flat with no infrastructure overhead. Break-even is usually 1-3 Lambda functions in regular use.
Largely yes. QueryFlow's Flow Books run Python 3.12 with pandas, numpy, requests, boto3, paramiko, and other common libraries pre-installed. Most Lambda ETL code translates directly — replace the Lambda handler signature with a Flow Book cell, use QueryFlow's connections instead of boto3 Salesforce clients, and the rest of the data logic works as-is.
Lambda auto-scales to handle bursts — if 1,000 events arrive simultaneously, Lambda spins up 1,000 concurrent executions. QueryFlow doesn't try to compete with that for event-driven workloads. For scheduled batch pipelines (the common ETL use case), auto-scaling rarely matters — a daily job is a daily job regardless of how concurrent it could theoretically be.
Three steps. Step 1: copy the data-processing core of your Lambda function into a QueryFlow Flow Book Python cell. Step 2: replace AWS-specific patterns (boto3 Salesforce client → QueryFlow Salesforce connection, Secrets Manager → Keychain, EventBridge trigger → QueryFlow schedule). Step 3: test interactively in QueryFlow, schedule when satisfied, and disable the Lambda trigger. Most migrations take 30-60 minutes per function.
Yes — for those event-driven triggers, Lambda remains necessary. Hybrid setups are common: keep Lambda for the event-driven layer, use QueryFlow for the scheduled batch layer. Together they cover most data engineering needs without QueryFlow trying to be everything.
14-day free trial. Migrate one Lambda function to QueryFlow this week and feel the deployment loop disappear.