Platform architecture

Astrato is a hosted application. Your data stays in your own database or warehouse: Astrato connects to it through a data connection, turns each question into SQL, and runs that SQL there when someone asks. This page explains the parts involved, for the people who approve a connection, a firewall rule or a security review.

Queries run in your database

When a chart, a Data App, Nash or an AI assistant asks for data, Astrato sends a query to your database through the data connection, and your database computes the answer. Astrato does not load your tables into storage of its own first. The rows come back to whatever asked: the chart, the conversation or the client.

Because the work happens in your database, its own controls still apply. It sees an ordinary SQL session from the user saved with the connection, or from each person’s own user where the connection supports that (see Sign-in and data access), and it bills compute, logs queries and keeps any result cache of its own as it normally would.

Some features write to your database rather than read from it, and only on a connection that allows writes. A CSV upload becomes a new table in a schema named Astrato in your database, not in Astrato. A scheduled metadata export writes your workspace’s metadata tables into a schema you choose.

The semantic layer and the engine

A semantic layer describes your data once for everyone: the tables it reads, how they join, and the measures, dimensions and security rules built on them. Workbooks, Data Apps, Nash and AI assistants ask their questions in terms of that model, not in SQL.

Astrato’s engine turns each request into SQL for your source’s dialect, using the model’s joins and definitions, and runs it through the data connection. Queries read the layer’s published version; saving is not publishing, so a saved draft changes nothing people see until it is published. A published Data App is pinned to the layer revision it was published against: once the layer is published again, the app stops serving until it is published again too; see Hosted app sessions. Data Explorer can query the current draft where the connection supports it; see Exploring an unpublished draft.

Where queries come from

A data connection’s Deployment Region decides where Astrato’s queries reach your database from. It does not move your database. Each region is an exit node at a cloud provider and region, such as Google Cloud europe-west2, and your workspace can also have private nodes, listed under their configured names. A connection left at Legacy / not selected is queried from Astrato’s own addresses. Either way, your database must accept traffic from Astrato: the addresses the connection form names under the selected region, or Astrato’s fixed addresses for Legacy / not selected; see Allow Astrato’s addresses. Deployment Region appears only when exit-node support is enabled for your workspace, and publishing a Data App requires a connection with a region other than Legacy / not selected.

With a Deployment Region selected, connection validation and schema browsing in the editor go from your browser to that region’s exit node, and a published Data App’s browser queries the exit node directly. The browser must therefore be able to reach it. Validate Connection sends the credentials you entered from your browser to the exit node, and saving sends them to Astrato, which stores them encrypted. Catalog browsing through MCP runs on Astrato’s servers. See Choose a Deployment Region and Direct access to Deployment Regions.

A database with no public address can be reached over a private path instead. On AWS, that is AWS PrivateLink or an AWS Transit Gateway, set up together with Astrato; see Private networking on AWS. For Google Cloud or Azure, see Databases with a private address.

Where Astrato runs

Astrato’s application and services run on Google Cloud. You use them at https://app.astrato.io, or at another Astrato origin your organisation has been given; see Authentication.

A published Data App is served from a Data App location, which by default follows the data connection’s Deployment Region and can be set to another available location. The location changes where the app’s files are served from, not where its queries go: those always go from the viewer’s browser to the connection’s exit node. See Hosting and data access.

What Astrato stores

Astrato keeps what it needs to run your workspace. It does not copy your warehouse’s tables, but some of what it keeps can contain values your queries returned, such as a stored Nash conversation. It keeps:

• Your workspace: people, groups, roles, access, sign-in configuration and settings.
• Data connections: each connection’s details and credentials. Secrets such as a password are stored encrypted, each under its own key.
• Semantic layers: the model, its drafts and its version history. An inline table, a small table of up to 100 cells typed into the layer, is stored as part of the model; see No writable connection?. A driver question saved as a next business question keeps its finding: a sentence and evidence with the labels and values its answer showed when it was created.
• What people build: workbooks, dashboards and the files of published Data Apps.
• Nash conversations, only if you allow it. A stored conversation keeps what was asked, Nash’s replies and the steps it took, including a preview of the rows its queries returned, so it can contain your data. Store Nash chats is off by default. While it is off, a new conversation lives only in the browser it was held in. Conversations stored while it was on stay in Astrato but are hidden until you turn it on again. See Store Nash chats.

Sign-in and data access

Two separate checks stand between a person and a row of data.

Astrato checks who you are and what you may open. A request is made as the person who signed in, and anything it does is done as that person; public Data Apps, below, are the exception. People sign in with a password or through your identity provider with single sign-on, and SCIM provisioning can manage their accounts and groups. Administrators can restrict access to the workspace by IP range; hosted Data App sessions do not enforce these ranges in the current preview (see Hosted publication sign-in). Roles, groups and resource access then decide which semantic layers, data connections, workbooks and Data Apps each person can open; see How access works.

Scripts, AI assistants and the CLI sign in as a person too, with OAuth or a personal access token, and get no more than that person’s permissions. A hosted Data App that is not public signs its viewer in to Astrato and receives a short-lived data token for its exit node, never the viewer’s main sign-in; see Hosted publication sign-in.

A Data App can also be made public, where your environment offers it and an Owner or Administrator has turned on External embed links. A public Data App opens without a sign-in, and its viewers query under an anonymous identity. It can read data only through a connection that uses one shared credential, and only from a semantic layer and data connection that are both Visible to everyone. See Public access and embedding.

Your database decides what that sign-in may read. A connection reads data either as the one user saved with it, for everyone, or as each person’s own database user:

• With one shared user, everyone reads through the same grants. Restrict rows per person in the semantic layer with a security rule, which compares a field with the email address or groups of whoever is asking, when the query runs.
• With per-person access, such as Sign in with Snowflake or identity federation, your warehouse applies its own grants, row access and masking policies to each person. See Shared or per-person access to Snowflake.
• A dynamic connection uses each viewer’s own connection settings in published workbooks, on Google BigQuery and ClickHouse.

To sign your own product’s users in to embedded Astrato content, see Sign your own users in.

AI features and your data

Nash runs on Astrato’s servers and acts as the person using it: it reads and changes semantic layers, and queries data, with that person’s permissions. Its replies come from the AI provider chosen as the Nash provider, so what you ask, and the results Nash reads to answer, go to that provider. Insights sends a visualisation’s query results to the Insights provider. See Which provider each capability runs on.

To keep Insights requests inside your own Snowflake account, choose a Snowflake Cortex LLM provider as the Insights provider. Nash cannot use Cortex LLM. See Snowflake Cortex LLM runs in your warehouse.

What next

• Data connections to connect a database and choose its Deployment Region.
• How access works to plan roles, groups and resource access.
• Set up single sign-on to sign people in through your identity provider.
• AI providers to decide where AI requests go.