In [Data Architecture Turned Upside Down](https://www.youtube.com/watch?v=DxwDaoUijTc), [Hannes Mühleisen](https://www.linkedin.com/in/hfmuehleisen) makes a simple point: in modern analytics, scan sizes are often much smaller than our mental model suggests — for an average analytics query or question, the median data scanned by the engine is around **100MB**, and even the far tail is "large but plausible".
A lot of analytics architecture still assumes one direction of travel:
> data lives "over there", compute lives "over there", and the user sends queries "up".
But if scans are frequently in the "downloadable" range, then a question follows:
> What if a meaningful chunk of analytics compute doesn't have to happen in a warehouse at all?
That question opens up a hybrid model we're excited about at Altertable
: **storage stays hosted**, but **compute can move** — running either on our
bare-metal servers or on your machine.
Not _everything_ should be client-side. But a lot more _can_ be.
## Why client-side analytics is suddenly plausible
### Modern formats keep scans small
Open columnar formats let engines **prune files**, **skip row groups**, and **read only needed columns** so most queries touch a narrow slice of the data, not the whole table.
### DuckDB makes modern CPUs feel like mini-warehouses
DuckDB is designed around **vectorized execution** (processing batches of values efficiently rather than row-by-row interpretation).
In real life, that means laptops with recent CPUs — like the MacBook Pros and Framework laptops we use daily — are genuinely fast at OLAP-style scans, filters, group-bys, and joins. For many average web app analytics tasks, a developer machine can compete with (or beat) a lot of production servers.
### "Tens of GB scanned locally" isn't fantasy anymore
Even when the scan grows beyond "small", [DuckDB’s memory management](https://duckdb.org/2024/07/09/memory-management) is built to be practical: it can work within a memory budget and spill intermediates to disk when needed.
We keep seeing "DuckDB processed 1TB" stories around the ecosystem — not because everyone has infinite RAM, but because the engine is designed to **keep making progress under memory pressure**.
## Altertable's foundation already fits this inversion
Altertable is built around a simple belief: your data shouldn't sit dormant in fragmented tools. It should be continuously explored, explained, and made useful — by humans _and_ always-on AI agents — inside one unified system.
Architecturally, we're already aligned with movable compute:
- [DuckDB](https://duckdb.org/) on our side for fast server execution
- [DuckLake](https://ducklake.select/) as the integrated data lake and catalog format
- [Cloudflare R2](https://www.cloudflare.com/products/r2/) as the object storage, with the important property that egress is free (so "download what you need" can actually be economical)
Learn how we're bringing battle-tested compaction strategies from search
engines to DuckLake
. So the hybrid idea is straightforward:
- **Storage**: an S3-like bucket (hosted by Altertable or owned by the user)
- **Compute**: either
- **Altertable servers** (bare-metal, always-on), or
- **your computer**
## The product upside: users bring compute
This is the part that feels almost too good:
- More users normally means more server load.
- With client-side compute, more users can also mean **more aggregate compute capacity**.
It also changes how we think about limits. Today, we cap **concurrent server queries** to keep costs predictable (while still allowing unlimited queries overall). With client-side execution, that cap could be _much_ higher for many workflows — and may not need to apply at all for "local mode".
## How hybrid execution could work in practice
This is the shape we’re exploring at a high-level.
### Classify the query
When you hit "Run", Altertable can estimate:
- likely scan size (from lakehouse metadata)
- join complexity / memory needs
- whether data governance policy allows local materialization
### Choose the compute location
Offer a simple switch:
- **Run on Altertable servers** (default for heavy, sensitive, or agent-driven workloads)
- **Run on my machine** (default for interactive exploration when policy allows)
### Stream only what’s needed
Because data is in open columnar files, the unit of work is naturally a subset of Parquet files / row groups / columns — not a proprietary warehouse block. The client can cache locally, reuse across charts, and stay snappy.
### Keep the UI identical
The most important constraint: it must still feel like Altertable.
Same dashboards. Same charts. Same definitions. Same exploration.
Compute location should be an implementation detail, not a UX fork.
## Our POC: building local mode with Tauri
We experimented with running client-side compute in a desktop shell. We chose [Tauri](https://tauri.app/) — a framework for building native desktop applications using web technologies. Unlike Electron (which bundles an entire Chromium browser), Tauri uses the **operating system's native webview**, making apps significantly lighter.
More importantly for us: Tauri's core is written in **Rust**, which integrates extremely well with our stack. A Rust-based desktop companion means we can **reuse parts of our server architecture** directly in the app — the same DuckDB workers, the same lakehouse logic, just relocated next to the user.
We built a POC where an Altertable dashboard ran on the laptop (not the server), with a multi-threaded DuckDB right next to the UI.
We looked at [DuckDB-Wasm](https://duckdb.org/docs/stable/clients/wasm/overview) too; it unlocks some great “no-install” flows. But today, there are constraints that matter for a serious hybrid system:
- threading and resource ceilings are tighter in browsers
- some extensions (e.g. [DuckDB-Postgres](https://duckdb.org/docs/stable/core_extensions/postgres)) you’d want in a full-featured setup aren’t available in that environment yet
WebAssembly is exciting, but for full-power local analytics a desktop approach is currently the most direct path.
## The boundaries: why hybrid doesn’t mean everything local
A hybrid model only works if it respects the hard constraints:
- **Some companies can’t allow data on laptops**, period. In those cases, local mode should be disabled by policy.
- **Some queries need big RAM and big iron**. If you want the fastest possible execution for huge joins, you want servers with hundreds of GB of RAM — and that’s exactly what our server-side compute is for.
- **Our always-on AI agents must run 24/7**, continuously exploring and monitoring your data. That should live on servers, not on a laptop that closes at 6pm.
We’re not trying to make Altertable client-only — we’re trying to make it **compute-flexible**, so the work runs in the right place by default.
## The "upside down" diagram we actually want
If you squint, the architecture flips:
- The lakehouse sits in the middle (open, portable, shared).
- Compute happens where it’s cheapest and most effective.
- Altertable is the layer that makes it one coherent system:
- one UI
- consistent semantics
- humans + agents collaborating
- and now: a choice of where the work runs
If you have opinions on what should run on your machine vs on servers, we’d love to hear them!