Columnar data lake tables

Call records, event logs and sales history are too large to page through row by row and too analytical for per-row edits. The usual answer is a separate warehouse with its own copies and its own permissions. The AutessaDB data lake stores this data in columns inside the same database, so "revenue by region by month" reads only what it needs and nothing has to be re-secured.

What you get

• ›Built for millions to billions of rows of events, logs, history and exports that arrive in batches and are read in aggregate.
• ›Columnar storage with partitions, so a query reads only the columns and date ranges it needs.
• ›Typed columns: STRING, INT, LONG, DOUBLE, DECIMAL(p,s), BOOLEAN, DATE, TIMESTAMP, TIMESTAMPTZ, STRING_LIST and JSON for nested values.
• ›Money-like numbers are suggested as DECIMAL(18,2) so totals add up exactly, and large numbers come back as exact strings.
• ›Read-only ANSI SQL with joins, common table expressions, subqueries, unions and window functions.
• ›Every query is an asynchronous job: wait for it, check back later, cancel it, or download the full result as CSV or Parquet.
• ›Each table has a SQL name, so one query can join every data lake table you can read.
• ›One platform: copy a relational table into the data lake in one step, and share it with the same access levels as every other table.

-- example

autessa autessadb analytics load --tableId V1StGXR8Z5 --localFile ./orders-2026-09.parquet

autessa autessadb analytics query --tableId V1StGXR8Z5 --output table --sql "
  SELECT region, SUM(net_amount) AS revenue
  FROM order_lines
  WHERE order_date >= DATE '2026-01-01'
  GROUP BY region
  ORDER BY revenue DESC"

Full reference in the AutessaDB CLI docs and the API reference.

◆ AI assist

Where AI helps

When you create a table from a file, Suggest descriptions with AI drafts the table and column descriptions before you create it. After that, Ask and data agents write SQL over the table using its semantic layer.

AI in AutessaDB works inside the same access rules as the person using it, and schema changes always wait for a person to apply them.