Data flows

Bring the data in, from anywhere

Drop a file, point at a web page, read another database, or generate records from a brief. SnoutData works out what it is, proposes the shape, and moves it where you need it.

SnoutData

One flow, start to finish. Every row in it is real, and the table at the end really exists.

SnoutData AcademyWatch the narrated walkthrough2 min 31 · chapters and subtitles

Four ways in

Drop anything, in any mix, in as many goes as you like. Nothing is read until you say so.

Files and PDFs

CSV, TSV, JSON, NDJSON, logs and PDFs, dropped in any number and any mix. Each one is identified by its content rather than its file extension, and anything the app cannot recognise it declines by name instead of guessing.

Web pages

Give it a URL and it fetches, renders and crawls. A page that builds itself in the browser is rendered first, so a client-side site is read as what a person sees rather than an empty container.

Databases

A table or a query from any connection you already have, read by keyset paging, so re-running an incremental flow moves only the rows that are new.

A model, with no file at all

Name the subject, the columns and how many, and a model writes the records. It runs on your own Ollama server, local or remote, or your own vendor key, and every record names the seed it was written from.

How a file gets read is your choice

Four options, in escalation order. Each one tells you where your data goes before you pick it, because that is a fact about the route, not a promise on a page.

The parsers, on this computer

The default. Structured files are read locally by code, and nothing leaves your machine. Fastest, free, and the only option that involves no model at all.

A model on this computer

For documents the parsers refuse. A local model reads them on your own hardware, so the data still never leaves the machine. It is downloaded on demand the first time you choose it.

Our AI

The managed gateway, metered against your plan. Use it when the local model is not enough and you would rather not run one yourself. Your content reaches a model in order to be read.

A model of your own

Your own key, your own provider. Requests go straight from your machine to them, so nothing passes through our servers and the billing relationship is yours.

A table is never handed over whole. Its header and a sample of its rows are used to work out how to read it, then the parser reads every row that way, so a large export costs one call and a few dozen rows of exposure. A document, which has no such regularity, is read in windows for as long as it takes, and there is no length at which a file is refused.

Shape it on the way through

Typed columns proposed for you, and every decision shown before it runs.

Typed columns, proposed

The structure advisor reads a sample and proposes the columns and their types, with a reason for each one. Repeating groups become child tables with a foreign key back, when the parent has a key.

Map, cast, derive

Rename, retype, split and combine, and derive new columns from the ones you already have.

Filter and dedupe

Keep the rows that matter and drop the duplicates, on the columns you choose.

Redact what should not travel

Personal data redaction is a stage of its own, so the sensitive columns never reach the destination.

Land it where it is useful

Five destinations, and the same flow can run to any of them.

A SQL table

Created for you or matched to one you already have, in any relational database you are connected to.

A MongoDB collection

Nesting kept rather than flattened, which is the inverse of the answer a table gives.

A file

CSV, JSON, JSONL, or a Markdown report you can hand to somebody.

A fine-tuning set

Validated JSONL, so generating a dataset and training something smaller on it is one path rather than two tools.

A vector index

Embedded and upserted into Pinecone, for retrieval over what you just brought in.

Runs you can account for

A flow is saved, repeatable and inspectable, not a script that ran once on somebody's laptop.

Schedules, with catch-up

Run a flow on a schedule, and it catches up on what it missed rather than skipping it. Part of Plus and Pro.

A run ledger

Every run records what it read, what it wrote and what changed, so you can account for the numbers afterwards.

Incremental by default

Cursors and content hashing mean a second run moves what is new, not everything again.

It explains itself

Before anything runs you see the proposed columns, the exact statements, and where the data goes. Nothing happens because the app assumed.

Get your data in

Free to start, on Windows, macOS and Linux.