Vision and Motivation

Vision & Motivation

Vision

Make serious data analysis as easy as opening a link: fast enough for millions of rows, private enough for sensitive data.

The problem: data lives in exports

Organizations run on systems that export data: ERP, MES, HRMS, CRM, ticketing tools, IIoT gateways, application logs. When someone needs an answer the built-in reports don't give, the usual path is export → open somewhere → analyze. That "somewhere" is where things break down.

Where people go	What goes wrong
Spreadsheets	Excel stops at 1,048,576 rows per sheet, and Google Sheets at 10 million cells per file. Lookups and pivots on large exports slow down or freeze. Joining two exports is painful.
Cloud BI tools	They need licences, setup, and someone to model the data. Uploading payroll, attendance, production or customer data to a third-party service is often not allowed.
Python notebooks	Powerful, but they need an environment, packages and programming skills that many of the people closest to the data don't have.
Desktop SQL tools	They need installation, which on managed corporate laptops often means an IT ticket and a wait.

The result: questions that should take minutes take days, get answered with sampled or truncated data, or don't get answered at all.

Why now

A browser tab today can do work that recently needed a server:

• WebAssembly runs compiled engines at near-native speed.
• DuckDB, an in-process analytical database with a rich SQL dialect and native CSV, Parquet and JSON support, compiles to WebAssembly as DuckDB-wasm.
• Apache Arrow provides a columnar in-memory format that moves between threads without expensive conversion.
• Web Workers, the Origin Private File System (OPFS) and SharedArrayBuffer (under cross-origin isolation) provide background execution, fast local storage and shared memory.

The engine is ready. What's missing is a product built around it that is fast end to end (not only at executing the query, but at loading, moving and rendering large results) and that speaks the language of the people who need the answers.

Why I'm building Blinkql

A note from the maintainer, Karthik

I'm a software engineer who has spent the last few years building and deploying enterprise software for manufacturing: ERP modules for asset and inventory management, an HRMS for factory workforces, and a Manufacturing Execution System covering production planning, quality, shift management and real-time IIoT dashboards.

Across dozens of customer deployments, one pattern kept repeating. Important operational questions (Why did OEE drop on Line 3 last week? Which failure reason costs us the most downtime? Does the stores issue register reconcile with what production actually consumed?) were very often answered from exported files, by capable people fighting tools that weren't built for the size or sensitivity of that data.

Blinkql is the tool I wish those teams had: one that opens instantly, handles their real data volumes, and never asks them to send that data anywhere.

It's also a deliberate deep dive into browser performance engineering. Keeping a UI smooth while a WebAssembly engine crunches millions of rows touches every layer: threading, memory, data formats, rendering and network. I'm building it in the open and documenting each optimization with reproducible benchmarks, so others can learn from (and challenge) the numbers.

Guiding principles

1. Your data never leaves your device. Privacy is enforced by architecture (there is no backend), not by policy.
2. Measure, don't guess. Every performance claim is backed by a reproducible benchmark. See Performance & Benchmarks.
3. The main thread belongs to the user. Heavy work happens off the main thread; the UI never freezes.
4. Zero setup. If something needs an install, an account or a config file, it needs a very good reason.
5. Simple first, powerful underneath. Templates and one-click actions for newcomers; full SQL for experts.
6. Decisions in the open. Significant choices are recorded as Architecture Decision Records.