QueryFlow Flow Books are SQL plus Python notebooks with shared state, native Mac performance, and one-click scheduling. The Jupyter alternative for data scientists who need their notebooks to run in production.
Jupyter changed how data work happens. It is also showing its age. The kernel startup wait, the notebook diffing problem, the gap between notebook and production — every working data scientist on a Mac has felt all three. QueryFlow's Flow Books take what works about Jupyter and fix what does not, while adding the one feature notebooks have always been missing: SQL cells that share state with Python cells automatically.
Jupyter is built around the IPython kernel. Every notebook you open spins up a kernel, every restart wastes seconds, and every crash takes the kernel with it. QueryFlow runs Python 3.12 locally as a bundled runtime. There is no kernel to start, no port to claim, no separate process to manage. Open a Flow Book and the first Python cell runs immediately.
Every data team has done this dance. You write a notebook that does something useful. You want it to run every day. So you copy the cells into a .py script, parameterize the inputs, configure cron or Airflow or a serverless function, and now you maintain two copies of the same analysis. The notebook drifts from the script over time. Bugs in production never appear in the notebook because the script has different connection setup, different error handling, different output paths.
QueryFlow eliminates the gap. A Flow Book is the production artifact. The same document you wrote interactively is the same document the scheduler runs at 9 AM tomorrow. There is no conversion step. The connections are the same. The cells are the same. The Python environment is the same. Right-click any Flow Book and choose Schedule — that is the entire deployment process.
This is the feature that does not exist in Jupyter. In a Flow Book, a SQL cell runs against your database connection and the result automatically becomes a pandas DataFrame in the next cell named df. No setup boilerplate. No SQLAlchemy connection string. No engine = create_engine() ritual. You write SQL, you write Python, the state flows between them because QueryFlow handles it.
# SQL cell
SELECT customer_id, region, total_orders
FROM customer_summary
WHERE signup_date > '2026-01-01';
# Python cell — df is already loaded
print(f"Loaded {len(df)} customers")
df.groupby('region')['total_orders'].sum().plot(kind='bar')
JupyterLab runs in a browser. JupyterDesktop wraps it in Electron. Neither feels native on macOS. QueryFlow is a real Mac app — pure Swift and SwiftUI, Liquid Glass surfaces, instant launch, native menubar, proper trackpad behavior. Tabs persist across sessions. The clipboard works. The window controls are where you expect them. Dark mode looks intentional. Apple Silicon and Intel Macs both ship as universal binaries.
QueryFlow ships with pandas, numpy, matplotlib, plotly, requests, openpyxl, pyarrow, paramiko, and boto3 pre-installed. No pip install. No virtualenv. No conda environment to manage. The runtime is local — your data never leaves your Mac unless you explicitly write it to a cloud destination. For data scientists who want to do real analytical work without the environment-management overhead, this is a meaningful improvement.
Claude AI is integrated into QueryFlow with awareness of your notebook content. Ask Claude to write a Python cell that groups your DataFrame by region and plots a histogram, and it writes the code. Ask Claude why your SQL is slow and it reads the query and the execution plan. The AI sees your schema, your code, and your recent errors — exactly the context a senior teammate would have if they were sitting next to you.
Jupyter is excellent for exploration but it has well-known production friction. The kernel takes time to start. Notebooks do not version-control cleanly because the JSON file includes cell outputs and metadata. Going from notebook to scheduled production job typically means rewriting the notebook as a Python script and setting up a separate scheduler — work that has nothing to do with the actual analysis. QueryFlow's Flow Books solve all three problems.
A Flow Book is QueryFlow's notebook format. It supports both SQL cells and Python cells in the same document, with state automatically shared between them. When a SQL cell runs, its result becomes a pandas DataFrame named df in the next Python cell — no setup code, no import statements, no manual passing of data between cells. Flow Books can be scheduled directly to run on cron or interval without conversion.
QueryFlow ships with Python 3.12 and the most common data libraries pre-installed: pandas, numpy, matplotlib, plotly, requests, openpyxl, pyarrow, paramiko, and boto3. These cover the majority of analytical work. If you need additional libraries beyond this set, the runtime is Pyodide (CPython compiled to WebAssembly), which supports a wide range of pure-Python packages. Heavily compiled libraries that require native extensions may not work.
Not directly today. Flow Books use their own format optimized for SQL plus Python state sharing. Migrating a notebook typically means copying the code cells over and replacing the manual database connection setup with QueryFlow's native connections. Most users find that the cleanup actually improves their notebooks because the connection-management boilerplate disappears.
Yes. Plotly HTML output renders inline using WKWebView, matplotlib plots render as inline images, and pandas DataFrames render as interactive tables. The output panel below each Python cell streams stdout and stderr live as the code executes — same model as JupyterLab.
QueryFlow is on the Mac App Store with a 14-day free trial. Open a Flow Book, run a SQL cell, transform with Python, and schedule the whole thing — in 60 seconds.