Search Docs…

Search Docs…

Search Docs…

Data Handling & Privacy

Data Handling & Privacy

When you connect Seedfast to a database, it's natural to ask: "What exactly leaves my machine?" This guide provides a clear answer about how Seedfast handles your data.

Seedfast uses an external AI provider to plan and generate a seeding strategy: ordering inserts, satisfying constraints, and producing realistic synthetic datasets.

What Seedfast Does NOT Send

Seedfast is built with privacy at its core. Here's what never leaves your environment:

Passwords, DSNs & Credentials

Seedfast masks credentials on the client side (inside the CLI) before anything is transmitted:

password=***

postgres://user:pass@host → postgres://*:*@host

The same applies to API tokens — they're automatically masked before any request is made. The AI provider never sees raw DSNs, passwords, or secrets.

How Seedfast Handles Your Data

Seedfast generates synthetic data from scratch. The AI uses your schema structure to understand relationships and constraints, then produces fresh, realistic values.

User Authentication Tokens

User auth tokens are stored on Seedfast infrastructure and are not forwarded to the AI provider.

What Seedfast Sends to the AI Provider

Seedfast sends only what is needed to build a correct, constraint-aware seeding plan:

Database Schema Metadata

Seedfast sends the following metadata:

  • Table names (e.g., schema.table_name)

  • Column names and data types

  • NOT NULL / nullable constraints

  • Max length for varchar fields

  • Foreign key relationships

  • UNIQUE and CHECK constraints

This information ensures the generated data respects your database structure and constraints.

User Scope Decisions

If Seedfast asks you to confirm what should be seeded or included in scope, your approve/reject responses can be sent as part of the planning context.

Why Schema Metadata is Needed

To generate valid synthetic data, a tool must understand your database rules: which columns can't be null, which values must be unique, which rows must reference other tables, and which constraints must hold.

Without this metadata, seeding becomes guesswork - resulting in FK violations and broken constraints.