Why I Stopped Uploading SQL Dumps to the Cloud

I recently analyzed a 4.2 GB PostgreSQL dump from a legacy e-commerce platform. The query planner was choking on a single join between orders and order_items. Usually, this kind of deep structural analysis requires loading the schema into a temporary cloud instance, running EXPLAIN ANALYZE on a subset of data, and waiting for the results. It’s a process that feels less like debugging and more like logistics management.

I wanted to know if the bottleneck was a missing index or a fundamental normalization failure. I didn’t want to spin up an EC2 instance for ten minutes. I just wanted to look at the data.

This is why I built SchemaSync. It’s an offline browser tool that analyzes raw SQL dumps to detect indexing bottlenecks and suggest normalization strategies. The core premise is simple: modern browsers are powerful enough to handle heavy lifting, but we’ve forgotten how to use them for developer tooling.

The WebGPU Wedge

The biggest hurdle in building SchemaSync wasn’t the SQL parser; it was the memory management. A 4GB SQL dump contains millions of tokens. Parsing this in JavaScript using standard Web Workers is possible, but it’s slow. The real breakthrough came from leveraging WebGPU.

By offloading the heavy tokenization and dependency graph construction to the GPU, we can process these files in real-time. There is no server. There is no upload step. The file stays on your machine, and the analysis happens in your browser’s sandbox.

This approach solves a specific pain point: the fear of data leakage. In enterprise environments, uploading production SQL dumps to third-party analysis tools is often a non-starter due to GDPR or HIPAA compliance. SchemaSync removes that friction entirely. If your machine can open the file, it can analyze it.

Beyond Basic Index Suggestions

Most schema tools stop at "you should add an index on this column." They are useful, but they miss the forest for the trees. SchemaSync tries to look at the structural relationships between tables.

For example, it can detect when a table is likely denormalized for read performance but is causing write bottlenecks due to redundant data updates. It identifies patterns like transitive dependencies in foreign keys that suggest a missing intermediate table.

Here is a simplified example of the kind of output it generates when it detects a potential normalization issue:

{
  "table": "user_profiles",
  "issue": "transitive_dependency",
  "details": "Column 'department_name' depends on 'department_id', which is also a foreign key.",
  "suggestion": "Extract 'department_name' into a separate 'departments' table to reduce update anomalies.",
  "confidence": 0.92
}

The confidence score comes from a small model that runs in your browser. It doesn’t have access to the entire internet or a massive training set like a cloud-based LLM. Instead, it uses a private on-device AI engine trained specifically on SQL schema patterns. This means the suggestions are consistent and fast, without the latency of an API call. It’s not trying to be a general-purpose assistant; it’s trying to be a specialist analyst.

The Trade-offs

It’s important to be honest about the limitations. Because this runs entirely on your local hardware, it is bound by your RAM and GPU capabilities. If you try to load a 50GB dump on a laptop with 8GB of RAM, the browser will crash. There is a hard ceiling.

Additionally, the analysis is static. It looks at the schema structure and the metadata within the dump. It cannot see the runtime query patterns or the actual data distribution unless you provide sample data. It tells you what the structure should be, not necessarily how the application is using it.

This tool is paid, with a 7-day trial. I built it because I was tired of the friction between identifying a problem and verifying the solution. For most developers, the cost is justified if it saves even one hour of trial-and-error optimization.

Is Local-First Tooling the Future?

We’ve spent the last decade moving everything to the cloud. SaaS has won. But as models get smaller and browsers get more powerful, I think we’re seeing a pendulum swing back toward local-first developer tools. The privacy benefits are obvious, but the latency benefits are just as significant.

I’m curious to hear from others who work with large SQL databases. How do you currently handle schema analysis for sensitive data? Do you use local tools, or do you trust cloud services with your raw dumps? And have you experimented with WebGPU for anything other than graphics?