Control · Data

A SQL database your AI apps can use

Every ContextGate workspace has a built-in database. Your AI apps land tool results as tables, query them with SQL, and read the files already in your own buckets as virtual tables. You see every table, run your own queries and roll back any change.

Get started free How it works

Included in every workspace. Nothing to install or host.

Results that outgrow the chat

A list of 4,000 deals or 900 tickets does not fit in a conversation. The AI app gets a page at a time, forgets the early pages, and answers from a sample. Landed in a table, the whole list is one SQL query away.

Files you already have

Exports and reports already sit as Parquet, CSV and JSON files in a bucket. Registered as a virtual table, a file is queried where it is. Nothing is copied into ContextGate and no pipeline is built.

One place to look

The tables, the SQL console and the version history are on the Database page of the workspace. You see what the AI app built, run your own queries, and roll back a change that should not have happened.

How it works

From a list in some app to an answer in SQL

Connect your AI app
Add ContextGate to Claude, ChatGPT, Cursor, Claude Code or any other app that supports remote MCP servers, and sign in. The database tools appear next to the tools of your connected apps.
Setup for each AI app →
Land the data
Ask the AI app to pull every page of a list (deals, contacts, tickets, repositories) into a table. One tool call loops the pagination, writes the rows and returns a short summary, so the raw pages never enter the conversation. Rows the app already has go in with one import call.
Ask in SQL
The AI app writes DuckDB SQL: joins, window functions, PIVOT, SUMMARIZE for a profile of every column. Results come back to the chat, capped in rows so a wide table cannot flood the conversation. Tables and views it creates stay for the next question.
Check, and undo if needed
The Database page lists every table and view with its schema and a sample, and has a SQL console of your own. Every write is a snapshot: restore to an earlier version, and forward again if that was wrong.

Example · execute_sqldeals landed from a CRM

SELECT date_trunc('month', won_at) AS month,
       count(*) AS deals,
       round(sum(value)) AS value
FROM pipedrive_deals
WHERE status = 'won'
GROUP BY ALL
ORDER BY month DESC
LIMIT 6;

month	deals	value
2026-10-01	41	318,400
2026-09-01	37	276,950
2026-08-01	29	201,300
2026-07-01	44	352,100
2026-06-01	38	289,700
2026-05-01	33	244,050

6 rows · the AI app asked in plain words; ContextGate ran the SQL it wrote.

Virtual tables

Your files and databases, as tables, where they are

A virtual table is a name that points at data outside ContextGate: files in your own object storage, or a table in your own database. Querying it reads the source at that moment. Nothing is copied or synced, so the answer is as fresh as the file, and a dataset far too large for a workspace table is still one query away.

Object storage

Amazon S3
Google Cloud Storage
Azure Blob Storage
Cloudflare R2

Parquet, CSV, JSON and JSON Lines. One object, or a pattern such as exports/2026/**/*.parquet.

Databases

PostgreSQL
MySQL

A table in your own database, read through the connection. ContextGate never writes to it.

Adding one

1.Add a data-source connection on the Connections page: the bucket or database, and its credentials. Credentials go to the secret store and are never shown again.
2.Browse the bucket, pick a file or type a pattern, name the table. ContextGate reads the path once to validate it and shows the columns it found.
3.Query it. Your AI app can add virtual tables too, with the same connection, when you ask it to.

Kept in bounds

A connection reaches one bucket or one database with its own credentials. A virtual table can only add a key or pattern inside it.
Hosts that resolve to private networks are refused, and a failed connection returns a plain message, not the provider's error.
ContextGate only reads from a source. It never writes to your bucket or your database.

Example · a virtual table over Parquet files

-- orders_2026 is a virtual table over
-- s3://acme-exports/orders/2026/**/*.parquet
SELECT region, sum(revenue) AS revenue
FROM orders_2026
GROUP BY ALL
ORDER BY revenue DESC;

The pattern matches every Parquet file under the 2026 folder. Add a month's export and the next query includes it.

SQL

DuckDB SQL, in a sandbox

The engine is DuckDB, so the AI app writes the SQL it knows best, with the analytical extras that save it a page of CASE expressions. Every statement is checked before it runs: a query can reach the workspace's tables and virtual tables by name, and nothing else on the server.

Allowed

SELECT, INSERT, UPDATE and DELETE
CREATE TABLE and CREATE VIEW, including CREATE TABLE AS SELECT
ALTER and DROP
DuckDB extras: GROUP BY ALL, QUALIFY, PIVOT and UNPIVOT, SUMMARIZE, SELECT * EXCLUDE, lists, structs and maps

Refused

Functions that read files, URLs, the environment or secrets
Attaching other databases, loading extensions, COPY and EXPORT
Settings and PRAGMA statements
Naming any catalog but the workspace's own: other workspaces' data is out of reach

Version history

Every write is a snapshot

The workspace database is versioned. Each table created, row inserted or view dropped adds a snapshot to the history. Restore to any earlier version from the Database page or by asking your AI app, and the restore becomes a new version of its own, so going forward again is just another restore. Trim the history by count or by age when you want to; the current version is always kept.

Virtual tables are versioned as definitions. The files and database tables they point at are yours, outside the history.

Limits

Workspace tables hold operational data at interactive scale: CRM pulls, lists to dedupe, aggregates. These limits keep one workspace from slowing down the others.

Rows in one workspace table: 250,000; Larger datasets stay where they are, as virtual tables
Rows returned by one query: 10,000; Aggregate or filter in SQL; the result says when it was cut
Time for one query: 30 seconds; Narrow the query rather than rerun it
Version history: Kept until trimmed; Trim by count or by age; the current version is always kept

For the AI app

The database tools

Listed to the AI app with the mgmt. prefix, next to the tools of your connected apps. The app picks them when you ask for a table, a query or an undo.

list_tables: Tables and views, with column and row counts
describe_table: Columns, types, row count and a five-row sample
execute_sql: Runs one SQL statement; SELECT results return to the chat
import_data: Creates, replaces or extends a table from rows the app has
fetch_paginated_to_table: Loops every page of a list tool straight into a table
create_external_table: Registers a virtual table over a connected source
browse_data_source: Lists folders and objects in a connected bucket
list_snapshots: The version history of the database
database_restore: Returns the database to an earlier version
delete_table: Drops a table or view, after the app confirms

Who can do what

Any member's AI app can list the tables, browse a connected bucket and read the version history. Running SQL, importing rows, adding virtual tables and restoring versions need an admin role in the workspace. Dropping a table makes the AI app confirm first.

Nothing else to connect

The database comes with the workspace. The AI app reaches it through the ContextGate connection it already has, under your sign-in. No database credentials are handed to the app, and the credentials of your buckets and databases stay in the secret store.

Each workspace on its own

Every workspace has a catalog of its own in ContextGate's hosted PostgreSQL on Google Cloud (US). A query cannot name another catalog, so a workspace's SQL reaches its own tables and virtual tables only.

Questions about the workspace database

Can Claude or ChatGPT query files in my S3 bucket?

Yes, through ContextGate. Add a data-source connection to the bucket (Amazon S3, Google Cloud Storage, Azure Blob Storage or Cloudflare R2), register a file or a pattern of files as a virtual table, and the AI app queries it with SQL like any other table. The files are read in place when a query runs; nothing is copied into ContextGate.

Which SQL does the workspace database speak?

DuckDB SQL, which is close to PostgreSQL with additions such as GROUP BY ALL, QUALIFY, PIVOT and SUMMARIZE, and first-class list, struct and map types. The statements allowed are SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, CREATE VIEW, ALTER and DROP.

Where is the data stored?

Workspace tables are stored in ContextGate's hosted PostgreSQL on Google Cloud (US), in a catalog of their own per workspace, and queried by DuckDB. Virtual tables are not stored: they point at files in your bucket or tables in your database, which ContextGate reads when a query runs and never writes to.

Who can run SQL in a workspace?

Can an AI app read arbitrary files or URLs through SQL?

No. The SQL sandbox allows the statement types listed on this page and refuses the functions that read files, URLs, the environment or other databases, as well as attaching databases, loading extensions and changing settings. A query can name the workspace's own tables and its virtual tables, and nothing else.

Can I undo what an AI app did to the database?

Yes. Every write is a snapshot. Restore the database to an earlier version from the Database page or by asking the AI app; the restore is itself a new version, so you can go forward again. Old versions are kept until you trim them.

Ready to see what your AI agents do?

Create a free workspace and add ContextGate to your AI apps in minutes. No card required.

Get started free

We'll email you a sign-in link to set up your workspace.

Rather talk it through first? Book a 30-minute call