Most products put a speed number on a marketing page and never show the work. This page does the opposite. Here is the exact query EcoCloud runs to list your tasks, run under EXPLAIN ANALYZE against 500,000 synthetic tasks, before and after the index that backs it — with the raw query plans, so you can check the math and reproduce it yourself.
The headline
348 ms
before — full workspace scan + sort
~2 ms
after — partial composite index
82×
faster, same query, 500k tasks
We used to assert "sub-80ms at 500,000 tasks" with no public proof. We measured it. As shipped, it was not true — the list query sorted the entire workspace and took 348ms. So we fixed the index, re-measured, and now it runs in ~2ms (warm) / ~4ms (cold). This page is the receipt.
What we measured
The query behind list_tasks (the MCP tool and the app's task list) — verbatim:
// the exact query under test
select id, title, priority, deadline, done, tags, created_at
from tasks
where deleted_at is nulland workspace_id = $1
order by created_at desclimit100;
Method: a throwaway workspace seeded with 500,000 rows via generate_series, then EXPLAIN (ANALYZE, BUFFERS) on the query above. Synthetic data was deleted immediately after; the index is permanent. Numbers are query-layer execution time on the database — they do not include client network round-trip.
Before — the plan that was actually shipping
With only a single-column index on workspace_id, Postgres scanned every one of the 500,000 rows in the workspace, then top-N heapsorted them to return 100:
// EXPLAIN before — what was actually shipping
Limit (actual time=347.957..347.975 rows=100)
-> Sort (actual time=347.955..347.963 rows=100)
Sort Key: created_at DESC
Sort Method: top-N heapsort Memory: 38kB
-> Index Scan using idx_tasks_workspace on tasks
(actual time=0.072..213.888 rows=500000)
Index Cond: (workspace_id = $1)
Filter: (deleted_at IS NULL)
Execution Time: 348.668 ms
213ms just to fetch the 500k rows, then a sort — to hand back 100. That is the textbook "fast in the demo, slow at scale" trap the review warned about.
The fix — one partial composite index
// the fix — one partial composite index
create index idx_tasks_ws_created_active
on tasks (workspace_id, created_at desc)
where deleted_at is null;
It matches the query's predicate and order exactly, so the planner walks the index in created_at desc order and stops after 100 — no full scan, no sort. Partial (where deleted_at is null) keeps it small and excludes soft-deleted rows, which is exactly what the list paths ask for.
After — the plan that ships now
// EXPLAIN after — the plan that ships now
Limit (cost=0.42..4.54 rows=100) (actual time=0.033..0.075 rows=100)
-> Index Scan using idx_tasks_ws_created_active on tasks
(actual time=0.032..0.066 rows=100 loops=1)
Index Cond: (workspace_id = $1)
Execution Time: 1.889 ms
Scenario (500k tasks)
Plan
Rows touched
Execution
Before
Index scan + top-N heapsort
500,000
348.7 ms
After (cold)
Index-only ordered scan
100
4.3 ms
After (warm)
Index-only ordered scan
100
1.9 ms
Because the plan is now an ordered index walk bounded by LIMIT, its cost grows with the page size (100), not the workspace size — it stays flat as the workspace grows past 500k.
Interactive — indexing at scale
The same result, made explorable. Drag the workspace size; the two curves are anchored to the measured 500k point above and extrapolated by the query-plan complexity. This is the one architectural lever we actually measured — not the tensor-IPC, actor-mesh or liquidity ideas we won't chart numbers for.
500,000
no covering index
348.7 ms
full scan + sort
partial composite index
1.9 ms
bounded index walk
speed-up
184×
same query
no index · ≈ O(N)indexed · ≈ flatmeasured at 500k
Anchored to one real EXPLAIN ANALYZE at 500k synthetic tasks (348.7 ms vs 1.9 ms); curves extrapolated from the query-plan complexity, not measured at every point. Query-layer execution time. Synthetic, not customer data. No money axis, no untested architecture claims.
What we do — and do not — claim
We stand behind
The list query runs in ~2ms at 500,000 tasks, measured by EXPLAIN ANALYZE
The plan is an ordered index walk bounded by the page size, so it holds as the workspace grows
The before/after plans above are the real, unedited planner output
Anyone can reproduce it with the SQL below
We do NOT claim
That this is customer data — it is 500k synthetic rows, generated and then deleted
An end-to-end interface latency number — this is query-layer time; network and render are separate
Anything about scale beyond 500k — we tested 500k; we reason about larger from the plan, we don't assert it
Multi-region, sharding, or "10M/workspace" — those are roadmap, not measured, and we won't pretend otherwise
Honesty > hype: we'd rather publish a real 2ms with its caveats than an unverified "sub-80ms" with none. The machine-readable version of these numbers is served at /api/v1/features with measured: true and a link back here.
Reproduce it yourself
Against any Postgres, seed a workspace and run the same plan. (EcoCloud runs on Supabase Postgres.)
// reproduce it yourself — any Postgres
-- 1. seed 500k tasks in a throwaway workspaceinsert into tasks (user_id, workspace_id, title, priority, done, created_at)
select $user, $ws, 'task '||g, (array['low','medium','high','critical'])[1+(g%4)],
g%5=0, now() - (g||' seconds')::interval
from generate_series(1, 500000) g;
-- 2. the index that makes the list query ordered + boundedcreate index idx_tasks_ws_created_active on tasks (workspace_id, created_at desc) where deleted_at is null;
-- 3. measure the exact shipped queryexplain (analyze, buffers)
select id, title, priority, deadline, done, tags, created_at
from tasks where deleted_at is nulland workspace_id = $ws
order by created_at desclimit100;
-- 4. clean up the synthetic rows (keep the index)delete from tasks where workspace_id = $ws;
// the governed loopsimulate→constitution→execute→signed→verifyES256 · audit-chained