Upside-Down Architecture

In Data Architecture Turned Upside Down, Hannes Mühleisen 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.

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 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.

Even when the scan grows beyond "small", DuckDB’s 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 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 on our side for fast server execution
• DuckLake as the integrated data lake and catalog format
• Cloudflare 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

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".

This is the shape we’re exploring at a high-level.

When you hit "Run", Altertable can estimate:

• likely scan size (from lakehouse metadata)
• join complexity / memory needs
• whether data governance policy allows local materialization

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)

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.

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.

We experimented with running client-side compute in a desktop shell. We chose Tauri — 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 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) 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.

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.

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!