Aamu.app Databases: a practical feature guide

Q: Who is Aamu.app Databases: a practical feature guide for?

This guide is intended for developers and technical teams.

Q: What does this guide explain?

It explains the main concepts, setup, and practical workflow for aamu.app databases: a practical feature guide.

Short answer: A practical reference for Aamu.app Databases: typed columns, views, filters, formulas and functions, relations, history, bulk editing, backups, automations, and APIs.

Aamu.app Databases are for structured work that needs more than a document but should stay connected to the rest of a team's workspace. A database can hold a CRM, content calendar, product catalogue, research collection, inventory, application pipeline, form responses, or the content for a public website. A database is at its happiest when it turns a pile of “we should probably track this” into something searchable.

The familiar starting point is a table with columns and rows. From there, Aamu adds saved views, filters, grouping, formulas, relations, bulk editing, activity history, automations, forms, portable backups, and APIs. This guide covers the current Database feature from everyday editing to external integrations.

Databases, tables, columns, and rows

A Database belongs to an Aamu project and can contain multiple tables. Each table has its own schema and rows, while tables in the same Database can be connected with reference columns and formulas.

A column has both a display name and a stable API identifier. The display name can be made friendly for people, while the identifier gives GraphQL, REST, CSV imports, formulas, and integrations a predictable field name. Rows also include created and updated timestamps in addition to the fields you define.

You can start with an empty Database, create one from a template, add more tables, duplicate a table with its rows, and rename or remove tables as the structure evolves. Deleted tables, columns, and rows go to the Database recycle bin instead of disappearing from the normal interface without a recovery path.

Column types

Column types define how values are edited, displayed, validated, exposed through the API, and used by other Database features. The current editor supports:

Text, Long Text, and Link for names, notes, descriptions, identifiers, and URLs.
Number for amounts, quantities, scores, percentages, and other numeric values. Number columns can have display formatting, precision, and a symbol.
Status for a single labelled choice and Checkbox for multiple choices.
Tags for reusable labels and categories.
Time & Date for one point in time and Timeline for a start and end range.
Location for a place with structured location data.
User for connecting one or more team members to a row.
Outside contact for connecting an Email contact to a row.
File and Files for one or several Aamu file attachments.
Document, Task, Email, and Meeting, each with singular and plural variants, for linking rows directly to other Aamu workspace objects.
Reference for relations between Database tables.
Formula for read-only computed values.

This mix is what makes a Database more than an isolated spreadsheet. A sales row can have a numeric deal value, a status, an owner, a follow-up date, related meeting notes, Tasks, Emails, and a reference to another table without copying all that context into text cells.

Grid editing

The table grid is the main view for dense data work. Cells use editors appropriate to their column type, and rows can also be opened in a details dialog when a record is easier to review vertically.

The grid supports spreadsheet-style selection and clipboard work. Select a rectangular range by dragging, copy it with Ctrl/Cmd+C, and paste tabular data with Ctrl/Cmd+V. A single copied value can fill a larger selected range. Pasting respects editable column types and leaves Formula columns read-only.

Aamu loads large tables in pages and renders the working window virtually. This keeps normal scrolling and editing practical without requiring the browser to render every row and cell in a large table at once.

Sorting, filtering, and searching

Click a column header to sort the table, or sort by row creation and update time. Database search can narrow the visible rows without changing the stored data.

Grid filters make repeatable subsets more precise. A filter can test whether a value:

is or is not equal to another value,
contains or does not contain text or a choice,
is empty or is not empty, or
is greater than, greater than or equal to, less than, or less than or equal to a value.

Multiple conditions can match either all conditions or any condition. The filter editor adapts the input to the selected column, so a Status field can use its configured choices while numeric and date-like fields use suitable values.

Saved Grid views

A Grid view saves a useful way of looking at one table. A view can store filters, sorting, hidden columns, grouping, and aggregate choices. Instead of rebuilding the same setup each time, select the saved view and continue working from it.

Views can be shared with the project or kept personal. This supports both team workflows and individual working views: the team can maintain a shared “Open applications” view while one person keeps a private view of records assigned to them.

When a saved view is changed, Aamu marks it as having unsaved changes. You can save the changes back to the view, save the configuration as a new view, rename a view, or delete one without modifying the underlying rows.

Grouping and summaries

Rows in the Grid can be grouped by a visible column. Groups can be collapsed, which is useful for scanning a large table by status, owner, category, customer, or another meaningful field.

A group can also calculate summaries for columns. Available aggregate operations include Count, Sum, Average, Minimum, and Maximum where the column type supports them. The same table can therefore show operational detail and lightweight summaries without exporting the data to a separate spreadsheet.

List, Kanban, and Calendar views

The same rows can be presented in views suited to different kinds of work:

Table is the full grid for editing, filtering, grouping, and working across many cells.
List presents records as individual row cards and is useful when each row has many fields.
Kanban uses a Status column as lanes. Moving a card changes the row's status and order.
Calendar uses a Time & Date or Timeline column to place rows on a calendar.

These are different presentations of the same records, not separate copies. An application can be triaged in a Kanban view, scheduled in Calendar, and edited in the Grid while keeping one underlying row.

References and relational data

Reference columns connect rows between tables in the same Database. A reference can point to one row or many rows, and Aamu can create an inverse reference on the other table when the relationship should be navigable in both directions.

For example, a CRM Database can have separate Companies and Contacts tables. Each Contact references a Company, while the Company row can show the related Contacts. A Projects table can similarly reference Customers, Deliverables, or Invoices without flattening everything into one oversized sheet.

The row details dialog shows both visible fields and references coming from other rows. New related records can be created from the relationship workflow, which reduces the need to jump between tables while entering connected data.

Formula columns

Formula columns calculate read-only values from the row. The formula editor suggests fields and functions, validates the expression, and previews a result from existing data before the column is saved.

Formula expressions are parsed by Aamu's formula engine; they are not evaluated as JavaScript. A formula can use literals, row fields, operators, parentheses, and the supported functions listed below. Function names are case-insensitive, while field names use the column's stable API identifier.

Values and field references

Text can use single or double quotes. Numbers support decimals and exponent notation. The literal values true, false, and null are also supported.

"Active customer"
125.50
true
customer_name
created_at
company.country

A simple field reference such as amount reads that field from the current row. Reference columns can be followed with dot notation, such as company.name. A one-to-many Reference produces a list, so following a field can produce a list of values.

Every formula row also has the built-in fields id, created_at, and updated_at. Dates use ISO-formatted values, and date functions use UTC.

Operators

Operators	Purpose
`+`, `-`, `*`, `/`, `%`, `^`	Addition, subtraction, multiplication, division, remainder, and exponentiation. If either side of `+` is text, the values are concatenated.
`==`, `===`, `!=`, `!==`	Equality and inequality. The double and triple forms currently use the same strict comparison behavior.
`>`, `>=`, `<`, `<=`	Greater than, greater than or equal, less than, and less than or equal.
`&&`, `\|\|`, `!`	Logical AND, OR, and NOT. AND and OR short-circuit.
`+value`, `-value`	Unary numeric conversion and negation.
`(...)`	Controls evaluation order.

Division or remainder by zero returns null. Numeric results must be finite; invalid numeric results produce a formula error.

Formula examples

IF(status == "won", amount, 0)
DATE_DIFF(created_at, TODAY(), "days")
CONCAT(company.name, " — ", contact_name)
SUM_FIELD(LOOKUP_RECORDS("LineItems", "order", id), "total")
IFERROR(company.country, "Country not set")

Lookup functions

LOOKUP_ONE and LOOKUP_RECORDS query another table in the same Database. The table name and condition field names are stable API identifiers written as strings. Conditions are supplied as field/value pairs and all supplied conditions must match.

LOOKUP_ONE("Companies", "domain", email_domain)

LOOKUP_RECORDS(
  "Invoices",
  "customer", id,
  "status", "open",
  "$order_by", "due_date",
  "$order", "asc",
  "$limit", 100
)

$order_by accepts a column identifier, id, created_at, or updated_at. $order is asc or desc. $limit is available to LOOKUP_RECORDS and can be from 1 to 1,000. LOOKUP_ONE always returns at most one record; LOOKUP_RECORDS returns a list.

Lookup functions require server-side Database data. The editor can validate the expression before saving, but a complete preview of a lookup may require saving the Formula so Aamu can evaluate it on the server.

Supported functions

Square brackets in a signature mark an optional argument. An ellipsis means that the function accepts more values up to the formula argument limit.

Logical functions

Function	Description
`IF(condition, value_if_true, [value_if_false])`	Returns one of two values based on a condition.
`IFERROR(value, fallback)`	Returns fallback when evaluating value produces an error.
`AND(condition, ...)`	Returns true when every condition is truthy.
`OR(condition, ...)`	Returns true when any condition is truthy.
`NOT(value)`	Reverses a boolean value.
`XOR(condition, ...)`	Returns true when an odd number of conditions are truthy.
`SWITCH(value, case, result, ..., [default])`	Matches a value to cases and returns the corresponding result.
`COALESCE(value, ...)`	Returns the first non-empty value.

Text functions

Function	Description
`CONCAT(value, ...)`	Joins values without a separator.
`JOIN(separator, value, ...)`	Joins values using a separator.
`LOWER(text)`	Converts text to lowercase.
`UPPER(text)`	Converts text to uppercase.
`TRIM(text)`	Removes leading and trailing whitespace and collapses internal whitespace.
`LENGTH(value)`	Returns the length of text or a list.
`LEN(value)`	Alias for LENGTH.
`LEFT(text, [count])`	Returns characters from the beginning of text.
`RIGHT(text, [count])`	Returns characters from the end of text.
`MID(text, start, count)`	Returns characters starting at a one-based position.
`SUBSTITUTE(text, search, replacement, [occurrence])`	Replaces all or one occurrence of text.
`REPLACE(text, start, count, replacement)`	Replaces characters at a one-based position.
`CONTAINS(text, search)`	Tests whether text contains a value.
`STARTS_WITH(text, prefix)`	Tests whether text starts with a value.
`ENDS_WITH(text, suffix)`	Tests whether text ends with a value.

Math functions

Function	Description
`ROUND(number, [precision])`	Rounds a number to a number of decimal places.
`ABS(number)`	Returns the absolute value of a number.
`FLOOR(number, [significance])`	Rounds a number down to a multiple.
`CEILING(number, [significance])`	Rounds a number up to a multiple.
`MOD(number, divisor)`	Returns the remainder after division.
`POWER(number, exponent)`	Raises a number to a power.
`SQRT(number)`	Returns the non-negative square root.
`MIN(value, ...)`	Returns the smallest numeric value.
`MAX(value, ...)`	Returns the largest numeric value.
`SUM(value, ...)`	Returns the sum of numeric values.
`AVERAGE(value, ...)`	Returns the average of numeric values.
`COUNT(value, ...)`	Counts non-empty values.

Relation functions

Function	Description
`SUM_FIELD(records, field)`	Sums a field from records returned by LOOKUP_RECORDS.
`AVERAGE_FIELD(records, field)`	Averages a field from records returned by LOOKUP_RECORDS.
`MIN_FIELD(records, field)`	Returns the smallest numeric field value from records.
`MAX_FIELD(records, field)`	Returns the largest numeric field value from records.
`COUNT_FIELD(records, field)`	Counts non-empty field values in records.
`LOOKUP_ONE(table, field, value, [field, value, ...], [$order_by, field], [$order, direction])`	Returns the first matching record from a Database table.
`LOOKUP_RECORDS(table, field, value, [field, value, ...], [$order_by, field], [$order, direction], [$limit, count])`	Returns matching records from a Database table.

Date functions

Function	Description
`NOW()`	Returns the formula evaluation time as an ISO timestamp.
`TODAY()`	Returns the formula evaluation date in UTC.
`DATE(year, month, day)`	Creates a UTC date. Month is one-based.
`YEAR(date)`	Returns the UTC year of a date.
`MONTH(date)`	Returns the one-based UTC month of a date.
`DAY(date)`	Returns the UTC day of the month.
`DATE_ADD(date, amount, [unit])`	Adds days, weeks, months, years, hours, minutes, or seconds to a date.
`DATE_DIFF(start, end, [unit])`	Returns elapsed days, weeks, hours, minutes, or seconds.
`DAYS_BETWEEN(start, end)`	Returns elapsed days between dates.

Info functions

Function	Description
`ISBLANK(value)`	Tests whether a value is null, undefined, or empty text.
`ISNUMBER(value)`	Tests whether a value is a finite number.
`ISTEXT(value)`	Tests whether a value is text.

List functions

Function	Description
`FIRST(values)`	Returns the first item in a list.
`LAST(values)`	Returns the last item in a list.
`NTH(values, position)`	Returns an item at a one-based position.
`UNIQUE(values)`	Returns unique list values while preserving order.
`SORT(values, [direction])`	Returns a sorted copy of a list; direction is asc or desc.

Evaluation behavior and limits

IF, IFERROR, AND, OR, and SWITCH evaluate lazily. A branch that is not selected is not evaluated.
NOW() and TODAY() use one consistent evaluation time for the formula calculation. TODAY() returns the UTC date.
DATE_ADD supports day, week, month, year, hour, minute, and second units in singular or plural form. DATE_DIFF supports day, week, hour, minute, and second units.
LEFT, RIGHT, MID, REPLACE, and NTH use one-based positions where a position is requested.
A formula can contain at most 4,096 characters, 1,000 tokens, 100 function arguments, 64 expression nesting levels, and a field path of 32 parts.
Reference traversal is limited to 10 levels. A lookup can return at most 1,000 rows.
A text result can contain at most 100,000 characters and an array result at most 10,000 items. Circular and non-finite results are rejected.

Formula errors are stored separately from the computed value and can be exposed through Database APIs. Use IFERROR when a fallback is an intentional part of the calculation; otherwise, let the error remain visible so an invalid field, date, lookup, or argument does not silently become misleading data.

Stable API identifiers are the field names used in formulas. Choosing clear identifiers makes the schema easier to use in formulas, CSV imports, GraphQL, and REST integrations.

Mass actions

Select multiple rows when an operation should apply to a set. Current mass actions can:

set or clear a value in an editable column,
duplicate selected rows,
copy complete rows as tab-separated values, and
move rows to the recycle bin or restore them.

Batch operations report how many rows succeeded and failed. This is useful for imports and operational tables where changing records one at a time would be slow.

Activity, undo, and redo

Every row has an activity timeline. It explains what changed, which field was affected, the previous and new values, who made the change, and when it happened. Related Docs, Tasks, Emails, Meetings, users, and referenced rows are rendered with useful names instead of only raw identifiers when that context is available.

Recent Database mutations can be undone and redone. Undo and redo are available from the activity workflow and through the familiar Ctrl/Cmd+Z and Ctrl/Cmd+Y or Shift+Ctrl/Cmd+Z shortcuts in the Grid. The history shows when a mutation has been undone.

This matters when a paste, bulk edit, or ordinary cell change affects real operational data. The team gets both an audit trail and a practical recovery action.

CSV import and export

A table can be exported as CSV for spreadsheet work, reporting, migration, or archival use. CSV rows can also be imported into an existing table.

During import, headers can match either a column's display name or its stable API identifier. Imported rows are appended to the table, values are parsed according to the destination column types, and Formula columns are ignored because their results are computed.

For repeatable integrations, use stable identifiers in the CSV header. Display names may be renamed for people, while API identifiers are designed to remain predictable for machines.

Portable Database backups

A Database can be downloaded as a portable .aamu.json backup. Unlike a table-level CSV, the backup preserves the Database structure: tables, columns, rows, references, saved views, and related definitions needed to move the structured application.

Restoring a backup is non-destructive. Aamu restores tables into the selected Database as new copies and remaps internal identifiers and references. Saved views are restored, while restored automations and forms remain drafts so potentially active workflows are not silently enabled.

Use CSV when the goal is to move rows in or out of one table. Use the portable backup when the schema and relationships matter too.

Forms and response data

Aamu Forms store submissions in a connected Database table. Form questions become typed columns and each submission becomes a row. Responses can then be filtered, grouped, reviewed in another view, connected to other records, or passed into an automation.

This pattern works for contact forms, surveys, applications, registrations, bug reports, and internal requests. The Form collects the input; the Database becomes the structured system of record for what happens next.

Database automations

Automations turn row events into workspace actions. An automation can react to a row being inserted or updated, optionally test conditions against its fields, and then perform one or more actions.

Typical workflows include creating a Task from a new form response, updating another Database row, sending a notification, or starting a newsletter-related action. Automation runs are recorded so the workflow can be inspected instead of behaving like an invisible background rule.

For safety, restored automations stay in draft status. Review their table references, conditions, and actions before enabling them in a restored Database.

GraphQL API

Every Database can expose a generated GraphQL schema based on the table and column API identifiers. Integrations can query rows and use mutations to insert, update, and delete data with typed fields.

query {
  CustomerCollection(filter: { status: { EQ: "active" } }) {
    id
    name
    email
    updated_at
  }
}

mutation {
  Customer(name: "Acme", status: "lead") {
    id
    name
  }
}

Requests use an API key and the Database id. The generated schema makes Aamu Databases useful as a lightweight backend for websites, small applications, content systems, and integrations. This blog itself uses a Database for post metadata and Docs for article content.

REST Database API

The team API also exposes the Database lifecycle directly. REST endpoints can create, inspect, rename, and delete Databases, tables, and columns; list, create, update, delete, and batch-process rows; manage automations; read activity; and run data transfer operations.

GET    /api/v1/databases/
POST   /api/v1/databases/
GET    /api/v1/databases/{dbId}/tables
POST   /api/v1/databases/{dbId}/tables/{tableId}/columns
GET    /api/v1/databases/{dbId}/tables/{tableId}/rows
POST   /api/v1/databases/{dbId}/tables/{tableId}/rows
PATCH  /api/v1/databases/{dbId}/tables/{tableId}/rows/{rowId}
POST   /api/v1/databases/{dbId}/tables/{tableId}/rows/batch
GET    /api/v1/databases/{dbId}/backup
POST   /api/v1/databases/{dbId}/restore

Row listing supports filtering, sorting, and cursor pagination. Batch writes can be made atomic when the integration needs all requested changes to succeed together, and idempotency support helps clients avoid repeating the same write after a retry.

A practical way to design a Database

Decide what one row represents: a customer, application, article, product, response, or another clear object.
Create typed columns for values you need to filter, group, calculate, or integrate. Keep longer narrative material in a linked Doc.
Use stable, readable API identifiers before connecting scripts or external applications.
Split repeated entities into another table and connect them with References instead of duplicating data.
Create shared views for team workflows and personal views for individual focus.
Add Form input, formulas, and automations only after the core row structure is understandable.
Export a CSV for tabular interchange and keep portable backups when the complete structure matters.

The bottom line

Aamu.app Databases combine the approachable table model of a spreadsheet with the structure of a small relational application. Rows can be edited in a Grid, List, Kanban, or Calendar; organized with saved views, filters, grouping, and summaries; connected with References and formulas; and changed safely with bulk tools, activity history, undo, and redo.

The feature becomes more useful because it is part of the wider workspace. Forms can create rows, automations can turn rows into actions, fields can link to Docs and other Aamu objects, and both GraphQL and REST APIs can connect the same data to external systems.

Use a Doc when the main thing is maintained writing. Use Tasks when the main thing is actionable work. Use a Database when the team needs structured records that can be viewed, related, calculated, automated, and integrated without leaving the project where the rest of the work lives.

Frequently asked questions

What is Aamu.app Databases: a practical feature guide?

A practical reference for Aamu.app Databases: typed columns, views, filters, formulas and functions, relations, history, bulk editing, backups, automations, and APIs.

Who is Aamu.app Databases: a practical feature guide for?