Frequently Asked Questions

Near-zero raw data egress means the scans and calculations that read your table values run inside your cloud environment. We don’t copy your warehouse into ours, or into any other service. Schemantic connects with the access needed for analysis, using service account credentials.

Some limited information leaves securely so we can give you a web interface and provide certain history enabled functionality, like lineage via query history. This may include things like structural metadata (e.g., table names), statistics about tables (e.g., min, max, averages, top 10 lists of values), logs, query history, and cached responses.

A statistic can obviously sometimes equal a value in your table, and a query input or response can contain a raw value, so we can’t claim total anonymity. That data is held in a tenant-isolated data plane, encrypted in transit and at rest, hashed where applicable, and deleted after termination on a dedicated retention purge cycle, with backups and disaster-recovery copies clearing on their own scheduled cycles.

We keep common operational records outside your environment — logs, telemetry, traces, diagnostics, and similar records — to run and support the product. They’re access-controlled, and we’re SOC 2 Type II attested.

These other exceptions apply only if you turn them on. Cross-cloud features: values leave only as one-way hashes or similar derived representations, never as raw values. AI features: things like prompts, tool results, and responses go to the provider you’ve authorized, and might include table values under the agreements and settings that apply. Authorize only what your organization permits.

This is the plain-language version. The official one — more complete, and the one that governs — is our Terms of Service; a good place to start is Data Handling, Cross-Cloud Features, and AI Features, though other sections apply too. If you’re running a security review or want further clarification, we’re happy to help. Please email [email protected].

See What happens when I enable AI-related features, like connecting an app over MCP?

Schemantic runs across the major enterprise warehouses — BigQuery, Databricks, Redshift, and Snowflake — and inside Google Cloud, AWS, Azure, or on-premise. The nine-element catalog is generally the same on every warehouse, so the catalog you install today travels if you switch stacks.

A context layer is most of what — perhaps everything — an analyst or AI agent needs to understand your warehouse: not just what to query, but what the data means, how it connects, and whether it's reliable. A semantic layer is one piece of that: it defines things like business metrics, validated join paths, access controls, and terminology in a governed model. A full context layer adds data quality signals, entity resolution across source systems, lineage metadata, and patterns discovered from query history. Applications query the context layer instead of raw tables, eliminating ambiguity and improving consistency.

When your organization enables AI functionality, such as Chat With Your Data, MCP, or AI-generated analysis, Schemantic sends the AI provider you select the inputs disclosed for that feature. These inputs may include structural metadata, aggregate statistics, descriptive statistics containing table values, and your prompts.

When you authorize an external AI application to connect to Schemantic’s MCP server, that application and its model provider receive your requests and the information returned by enabled tools. Depending on the tools and permissions you grant, this can include metadata, statistics, and table values such as minimums, modes, top-value lists, or query results.

These providers and applications may receive table values, and depending on which AI service you choose, they may retain them. Their processing, retention, and any use for model training are governed by your agreements and settings with that provider. Authorize only the providers, applications, and data access your organization permits.

User-approved joins rank highest, and our algorithm completes the sort for non-user-approved joins.

Yes. The path-finding tool constructs multi-step join paths in seconds. Each path includes a visual diagram and auto-generated SQL ready to copy.

Generally yes — every table selected during onboarding. Tables not included in onboarding are excluded unless explicitly added.

Most runs complete within several hours, many within an hour. The primary factor is the number of tables and columns.

The map only shows joins connecting tables currently in view to avoid visual clutter.

Approving or rejecting determines display in the map and use in path generation. If unsure, leave unreviewed. You can reverse decisions later, but actions are visible to other users.

Hours from initial authorization to viewing valid joins for many use cases. Large or complex datasets may take a few days. Extremely large environments (dozens or hundreds of terabytes) may take proportionately longer.

For petabyte-scale or further clarification, contact [email protected].

Four times per day to prevent accidental overuse. Request manual refreshes via [email protected].

For the most part, Schemantic scales with your cloud provider’s capacity.

Most comparable tools assume you already know how your data joins, or capture joins at the ELT/ETL level and recreate them per pipeline. Schemantic discovers joins from raw data and provides a collaborative interface for documenting and constructing SQL from those joins.

No. For recently ingested data, refresh and rerun. Data is current through the time the run was initiated. Allow 15 minutes for new data to be available before initiating.

Most questions are addressed in FAQ and documentation. Additional support via [email protected].

Follow your company's data security policies. The simplest option is granting Schemantic user licenses — cost-effective and the safest way to share data relationships.

For enterprise support, contact [email protected].

Email [email protected] with ideas or requests.