I built an audit-friendly SQLite viewer for VSCode because I stopped trusting marketplace extensions

Marioloez — Fri, 22 May 2026 06:14:43 +0000

Atalaya — Spanish for "watchtower". A high vantage point with a clear view over the territory below.

The uncomfortable question

Open VSCode. Search "SQLite". Pick the most popular extension. Run find node_modules -type d | wc -l after installing it locally. Most of them sit somewhere between 200 and 500 packages in their transitive dependency tree, plus native code bundled per platform.

For a tool whose single job is to read a .db file.

[TODO: drop a personal anecdote here — when did supply-chain risk in editor extensions stop being abstract for you? a coworker affected, a compromised package you remember, the recent xz-utils backdoor narrative, whatever feels honest. one paragraph max.]

When that's the surface a tool sits on, every extension you install is a trust decision you're making against your entire workspace: source code, environment variables, git credentials, the lot. And the threat is not theoretical — compromised VSCode extensions have shipped credential-stealers to thousands of developers in the last two years.

So I built one I could actually audit.

Meet Atalaya

Atalaya is a SQLite viewer for VSCode with a deliberately minimal footprint:

One runtime dependency in the shipped .vsix: sql.js, the official SQLite compiled to WebAssembly
Zero native modules — no node-gyp, no platform-specific compilation
Zero network calls, zero telemetry, zero remote resource loading
Strict CSP in the webview (default-src 'none' + per-load cryptographic nonce)
All SQL identifiers are allowlist-validated; all SQL values bound via prepared statements
MIT licensed, ~2,300 lines of code total

Features that actually matter

It opens .db, .sqlite, .sqlite3 files as a custom editor. From there:

Browse any table with pagination, type-aware coloring, sortable headers, per-column filters
Run arbitrary SQL from the Query tab with Ctrl/Cmd+Enter
Edit cells inline by double-clicking; Enter saves to memory, Cmd+S writes to disk
Undo and redo anything you ran in the SQL editor or edited inline — natively via VSCode's edit stack
Export any table or query result to CSV or JSON
Read-only fallbacks for views, tables without a primary key, and BLOB columns — the UI gets out of your way when it can't safely edit

The SQL editor has autocomplete — implemented in plain JS

I refused to pull in Monaco Editor because that's another ~5 MB of code I'd ask you to trust. So the autocomplete is hand-rolled vanilla JS. About 250 lines. It scopes column suggestions to whatever tables your query already references.

After FROM, JOIN, INTO, UPDATE it suggests tables. After SELECT, WHERE, AND, OR, ON, ,, ( and friends it suggests columns. Arrow keys navigate, Enter / Tab insert, Esc closes. Cmd+Enter runs the query — the popup never intercepts it.

It's not Monaco. It doesn't do alias resolution or syntax highlighting. That's the point. You can read every line of it.

Query results don't surprise you

Anything that modifies data — INSERT, UPDATE, DELETE, or DDL — marks the document as modified and goes onto the undo stack. Nothing touches the disk until you press Cmd+S. Close without saving to throw away mutations.

What "audit-friendly" actually means

I want to be honest about what this label does and doesn't promise, because it's the most important claim I'm making.

It doesn't mean invulnerable. Nothing is invulnerable.

It does mean every line of the runtime surface is short enough to read. Let me make that concrete:

TypeScript source (4 files): ~810 lines
Webview JS / CSS (viewer.js, viewer.css): ~1,460 lines
That's the whole story. ~2,300 lines.
Plus the bundled sql-wasm.js glue (~46 KB of code wrapping the WASM blob)
Plus the sql-wasm.wasm binary — opaque, but compiled from public, well-reviewed SQLite source

You can read all of the JS and TS in an afternoon. The WASM blob is what it is, but it's the SQLite the world has been using for decades.

I also paid for that minimalism in features. Things Atalaya does not have:

Schema visualization (coming, but only if I can do it without adding deps)
Multi-file workspace, query history, saved snippets
AI assistants, copilots, "smart suggestions"
Subscription, account, sync, anything cloud

This isn't a "minimum viable product". It's a deliberately small tool with a specific posture.

The receipts

Don't take my word. Verify it yourself:

git clone https://github.com/Marioloez/atalaya
cd atalaya
npm ci --ignore-scripts          # neutralize any postinstall hooks
npm ls --omit=dev --all          # show the production dep tree

That last command prints exactly two lines:

atalaya@<version>
└── sql.js@<version>

Then read src/sqlite/service.ts and src/editor/sqliteEditor.ts. They're short. They do exactly what they look like they do.

And if you find something I missed — open an issue. The whole point of this is that finding things is supposed to be possible.

A small clarification about the dev install

There's one caveat I want to surface, because anyone running npm install will see it immediately: my devDependencies tree pulls in @vscode/vsce (the marketplace packager), which transitively pulls keytar (a native module for credential storage). That keytar binary runs a postinstall script during npm install.

None of it ships in the .vsix. I verified by running unzip -l atalaya-*.vsix — only my own compiled code, sql-wasm.js, sql-wasm.wasm, README, LICENSE, CHANGELOG, and the icon. Zero @azure/*, zero keytar, zero native binaries.

But if you intend to clone and inspect the source, run npm ci --ignore-scripts to keep the install hermetic. I documented this in the README. The "audit-friendly" claim is about the shipped artifact, not about the build chain. Clarity matters more than marketing.

Install

code --install-extension marioloez.atalaya

Or search Atalaya in the VSCode Extensions view.

GitHub: github.com/Marioloez/atalaya
Marketplace: marketplace.visualstudio.com/items?itemName=marioloez.atalaya

Why this matters beyond Atalaya

I'm not trying to replace every SQLite viewer. Some people genuinely need the feature-rich ones, and that's fine — it's a tradeoff worth taking when the cost is acceptable to them.

But the default trust posture of "install the popular extension, accept the 300 transitive packages, move on" deserves more scrutiny than it currently gets in developer workflows. The cost of that trust is hidden right up until someone exploits it.

Build small. Show the receipts. Make verifying easy.

[TODO: close with a short personal line in your voice — what would you ask a reader to do next? "audit a single extension in your editor this week" / "let me know what you'd improve" / "tell me what other tools deserve a minimal-trust rewrite". keep it one sentence.]

Built with sql.js, the VSCode Custom Editor API, and a refusal to add dependencies.

DEV Community: Marioloez