I built Sheetscope, a service that ingests your documents (PDFs, spreadsheets, images, etc.) and lets you query them with SQL. You upload your files, define a schema (using a template, an example document, or a custom JSON Schema), then run queries across whichever documents you want.

The idea came from a bunch of my friends in data analytics complaining about bespoke scripts using regex or similar heuristics in an attempt to parse structured data from PDFs and other documents. Existing solutions either expose an API for extraction and leave persistence/querying largely up to you, or they only allow AI-powered workflows like “chatting with your data.” I’m initially targeting users who are technical enough to know their way around SQL but not necessarily comfortable with architecting and implementing an entire extraction pipeline.

AI is only used during extraction and optional schema generation; SQL queries run directly against the extracted data. Extraction is handled by Reducto, uploaded files are stored in object storage and kept until you delete them. The rows are stored alongside a reference to the source file, though direct citations are not yet implemented.

One part of the implementation I've spent a fair amount of time on is caching extraction work. Rows for a schema are not stored in one large table somewhere, they are independently materialized rows for each (upload, schema) pair. This means that extraction only needs to happen when we encounter an upload/schema combination we haven’t processed before. Queries over cached rows have been quite fast in my testing, and most of the overhead comes from creating a new tenant-scoped DuckDB client instance (~1s cold, ~50-100ms with a warm client and extractions cached).

My initial thinking has been things like invoices, statements, reports, exports, and other files that finance/ops people repeatedly need to pull data out of; I’d love to hear where else this workflow might be useful.

If that sounds interesting, please try out the free tier!