Skip to main content

​
Overview

A Data Store is a type of knowledge base that holds structured data instead of files. Where a document knowledge base stores files and lets agents search their text, a data store is a real Postgres database: tables, rows, and columns that your agents design and manage, and that your apps can read and write live. Reach for a data store when your agents need to track state that changes over time rather than cite fixed source material: A simple rule of thumb: cite it → document KB; update it → data store.

​
Isolation and security

Every organization’s data stores live in a dedicated, private database, separate from every other organization and from Aster’s own platform database. Access always flows through Aster’s API — connection strings are never exposed to agents, apps, or browsers, and each data store is reachable only by its own scoped database role. Cross-organization access is impossible at the database level, not merely disallowed. Locking a data store (the Lock button on its page, or asking an agent) freezes its structure. Only its creator or an org admin can then create, alter, or drop tables, columns, indexes, or views. Agents and apps can still read and write rows.

​
Creating a data store

From Control Hub

Go to Control Hub → Knowledge Bases, click Create Knowledge Base, choose the Data Store type, and give it a name. The first data store in your organization takes a few seconds to provision its database; after that, creation is instant.

Or let an agent create it

An agent can create a data store as part of building a solution, with manage_data_store (action: create_store) or manage_knowledge_bases (action: create, type: structured).

​
How agents work with a data store

Agents interact with a data store through three tools. By default an agent with these tools can use every data store in your organization; select specific stores in the agent’s settings to restrict it.
  • manage_data_store — evolve the schema: create, alter, and rename tables and columns, create indexes, and create views (saved SQL that apps can read like a table). Destructive changes require explicit confirmation.
  • query_data_store — read with full SQL SELECT (joins, aggregates, GROUP BY, window functions, CTEs). Results over 1,000 rows are returned as an attached CSV.
  • write_data_store — insert, update, delete, upsert, atomic multi-statement batch writes, bulk_load (load a JSONL file of up to 100MB in one transaction), and sql / sql_file for set-based updates you write yourself.
The agent always sees its data stores’ current schema in its context, so it knows what tables and columns exist without having to ask.

​
The data explorer

Open a data store in Control Hub and you get a built-in explorer:
  • A table list on the left and a live row preview on the right.
  • Pagination through large tables.
  • Export — download any single table, or the entire store, as CSV at any time. Your data is always yours to take.

​
Live data in apps

This is where data stores shine. An app bound to a data store can read and write rows live — a user checks a box or edits a value and the change is saved instantly, visible to teammates on their next refresh. There is no staging step and no need to republish the app. See Apps → Live data for how app builders use the useLiveTable and useDataStore hooks.

​
What a data store is not

  • Not a document store. It holds no files; file upload, semantic search, and extraction schemas don’t apply. Use a document knowledge base for those.
  • Not a connection to an external database. A data store is Aster-managed infrastructure. To work with a system your organization already runs, use that system’s integration instead.