Why FrameQuery Is Local-First (And Why Your Video Tool Should Be Too)
Your footage never leaves your machine. Your search index lives on your disk. Here is why we built FrameQuery as a local-first desktop app instead of another cloud platform.
Every other video management platform wants to upload your footage to the cloud. We went the other direction.
FrameQuery is a desktop application. Your videos stay on your drives. Your search index is a file on your disk. Search is instant, free, and works offline.
The problem with cloud-first video tools
Video files are enormous. A single day of shooting on a RED or Blackmagic camera can produce hundreds of gigabytes. Uploading that to a cloud platform takes hours, sometimes days, and costs real money in storage fees.
Once uploaded, you are locked in. Your footage lives on someone else's servers. If the company shuts down, raises prices, or changes their terms, your library is at risk. You are renting access to your own work.
Video professionals already have perfectly good local storage: NAS, RAID arrays, SAN. Uploading everything to the cloud is redundant and expensive.
How local-first works in FrameQuery
The architecture splits into two parts.
Processing (cloud). When you want to index a video, FrameQuery generates a lightweight proxy locally and sends only that compressed proxy to our processing servers. Your original footage never leaves your machine. The proxy gets analysed (transcription, object detection, face recognition, scene descriptions) and the results come back as a compact index file.
Search (local). The index file is saved on your machine. It is typically a few megabytes per hour of video. Searching this index is a local operation: no network requests, no API calls, no per-query costs. You can search your entire library in milliseconds, even with no internet connection.
You pay for processing (the expensive GPU work on our servers) but search is free forever. If FrameQuery disappeared tomorrow, your index files would still work.
Building it with Rust and Tauri
To make local-first work well, we needed a desktop app that felt native, not a web app crammed into an Electron shell. We chose Tauri 2 with a Rust backend and a React frontend.
Why Rust. Our backend does heavy lifting: decoding proprietary video formats (R3D, BRAW) via C/C++ FFI, managing SQLite databases, running FFmpeg pipelines, and coordinating GPU-accelerated processing. Rust gives us the performance of C++ with memory safety guarantees. No garbage collector pausing during a frame decode. No null pointer crashes during a long batch job.
Why Tauri over Electron. Tauri apps ship a native webview instead of bundling an entire Chromium browser. The FrameQuery installer is roughly 10 MB instead of 200+ MB. Memory usage is a fraction of what Electron would require. And because the backend is Rust, CPU-intensive work runs at native speed rather than in a Node.js event loop.
SQLite for everything. All metadata lives in a local SQLite database: video records, source folders, processing status, settings, search indexes. SQLite is single-file, portable, and fast. When you back up your FrameQuery data, it is one database file plus your index files. No server, no daemon, no Docker container.
What "offline-first" means in practice
It means you can:
- Search your entire indexed library on a plane with no Wi-Fi
- Move your index files to a different machine and keep searching
- Back up your FrameQuery data with standard file backup tools
- Recover your library from a backup without contacting any server
- Share an index with a collaborator who can search it on their own machine
The cloud is involved only for the initial processing step, where GPU compute is genuinely needed. Everything after that is yours.
Encrypted backups
Because your data is local, backups matter. FrameQuery includes built-in encrypted backup and restore using the age encryption standard. You set a password, and your entire library metadata gets encrypted into a portable file. Take it to a new machine, restore from the backup, and you are back to where you were.
The trade-off
Local-first is not free of trade-offs. You are responsible for your own backups. If your drive dies and you did not back up your index files, they are gone (though you can always re-process your videos to rebuild them).
We think this trade-off is worth it. Video professionals are already managing petabytes of storage. They know how to back up important files. What they should not have to manage is a monthly cloud bill just to search their own footage.
Join the waitlist to get the desktop app and see local-first video search in action.