The database for AI apps that knows who is asking.

AutessaDB is the database for apps and AI agents. You create typed tables, query them with filters, joins and aggregates, search them by meaning, protect them with row-level security and column masking, and automate them with triggers. Its columnar data lake holds billions of rows for SQL analytics, all from the builder, the REST API, the Autessa CLI or the AutessaScript SDK.

Yes. Create a table, drop in a file or start a data lake load, and it works the same day, with sharing, security and agent tools ready. Then you shape it to how your company works: your own columns, row rules and masks, triggers that run your tools and agents, a semantic layer in your own business terms, and apps built on your tables.

Yes. AutessaDB - Columnar is a data lake built into AutessaDB, with lakehouse-style columnar storage for millions to billions of rows such as events, logs, sales history and exports from other systems. You bulk-load CSV and Parquet files or existing tables, partition by date, query with analytical SQL, ask in plain language, and give agents tools to answer data questions, with the same sharing and row and column security as every other table.

Yes. One action creates three tools for the tables you pick: describe the tables, run a query, and read the result. An agent with them looks up what the tables contain, prefers your verified queries, filters on partition columns, and pages through long results, seeing only what the person or key it runs as may see.

Yes. Mark a Short Text, Long Text, File or Audio column for semantic search and every insert and update is embedded in the background, with no separate pipeline or re-index job. An AI step also enriches each value with a summary, key facts and likely questions, so search matches meaning, and it works next to ordinary filters on the same table.

Yes. Security roles carry a row rule per table, written as a filter with placeholders such as $CURRENT_USER_ID, $CURRENT_USER_TEAMS or $CURRENT_CUSTOMAPP_USER_ID, plus an edit check for changes. The same rules apply to every caller, whether a person, an agent, a script, an app or an API key.

Yes. Ready-made AutessaDB tools let agents insert, update, delete, query, aggregate, run semantic search, browse Drives and query the data lake with SQL. Agents act as the person or key they run as, so they see only the rows and columns that identity is allowed to see, and their writes fire triggers like any other write.

A trigger fires on INSERT, UPDATE or DELETE of a row, optionally only when specific columns change in a specific way, and runs a tool, an agent, a multi-agent or a write to another table. Row values pass in as @@{column} and @@{old.column}, and every firing is recorded with the row before and after and the response. Agents can also call or email a customer when a row changes, following your instructions.

Yes. The data lake answers read-only ANSI SQL, with joins, common table expressions, subqueries, unions and window functions, in the SQL Workbench, the CLI, the API, custom apps and agents. Relational tables use structured queries (filters, joins and aggregates), which is what lets them carry triggers and semantic search per row.

Mark a text column masked to store it encrypted, then decide per security role whether the column is visible, masked or hidden. Masked shows a full redaction, the last four characters or a consistent code; hidden removes the column entirely; and every reveal of a masked value is recorded in the access log.

Yes. The REST API lives at https://api.autessa.com/clients/autessadb with per-table API key permissions, the Autessa CLI has an autessadb namespace covering tables, queries, triggers, roles, the access log, Drives and analytics, and scripts use the autessa.autessadb SDK. All three apply the same row and column security as the web app.

Use a relational table for records people and agents read and change one at a time, with triggers, semantic search and row edits. Use the data lake for data that arrives in batches and is read in aggregate, such as events, logs and history, queried with SQL over millions to billions of rows. Both share the same sharing levels and row and column security, and you can load a relational table into the data lake in one step.

Yes. An append-only table accepts inserts and reads but refuses every update and delete. The setting is a one-way latch: it can be turned on but never off, computed columns are not allowed on it, and removing a column is refused because it would destroy history.

The AutessaDB security page explains row rules, masking, sharing levels and the access log, and the Autessa Trust Center at trust.autessa.com has Autessa's security documentation and compliance reports.