Skip to main content
This guide builds a working inventory tracker to teach the essentials of AppDB, Domo’s built-in document store for app data. You’ll define a collection, write and query documents, update them atomically, and aggregate on the server — all without a connector or refresh cycle.

Understand What AppDB Is

AppDB is a document database built into the App Framework. Your app reads and writes its own data directly — no connector, no ETL, no refresh cycle. Documents are free-form JSON, so the same collection can hold differently shaped records without defining columns first. Reach for AppDB when your app owns its data:
  • Use AppDB for state a user creates or edits inside the app — inventory, annotations, saved settings, form entries.
  • Use a Domo DataSet when data arrives from a connector, Workbench, or ETL, or exists mainly to power cards and dashboards.
Before you start: You need access to a Domo instance where you can create apps, and basic JavaScript knowledge. Everything runs in the browser-based Pro-Code Editor — there’s nothing to install.

Understand How AppDB Organizes Data

AppDB nests data in three layers. Your app gets one datastore, which holds collections, which hold documents. If you’ve used a relational database, the analogy is direct: Unlike a DataSet, AppDB doesn’t require a fixed column schema — documents in the same collection can have completely different shapes. That flexibility is what makes it useful for app-owned state.

Create the App

Go to Asset Library (your-instance.domo.com/assetlibrary) and select Pro Code Editor in the top-right corner. Select the Hello World template to create a new app.

Define a Collection

Collections are the primary unit of data organization in AppDB. In the Resources pane (bottom-left), under Collections, create a new collection named Inventory. Saving the appearing “Inventory” tab updates your manifest.json to include the collection:
Note: The manifest controls the collection, not the API. If you later update this collection through the API, the platform will overwrite your changes the next time the card is saved. To change a manifest-defined collection, edit the manifest instead. See Working with the Manifest.

Prepare the HTML

Replace your app’s index.html with the below, which
  • Adds an output container for feedback
  • Uses the latest version of domo.js
  • Makes your app.js a module so it can use async-await.
Note: This guide leads with the domo.appdb.* helpers from ryuu.js v6, which wrap your data in the content envelope for you and read more cleanly. The second domo.js v4 tab in each example shows the equivalent raw REST call for earlier SDK versions.

Create Documents

Because AppDB has no fixed schema, documents in the same collection can carry completely different fields — electronics carry warranty, furniture carries weight, and the notebook has neither. All live in the same Inventory collection with no schema change. Replace app.js with the following.
Save and verify the preview shows Created 5 items. You can preview the contents of your collections at any time. In the Pro-Code Editor, under “Resources”, click your collection. Or, once deployed, you can preview your collections in AppDB Admin.

Know the content Envelope

Every document stores its data inside a content “envelope”. You write only the content object; AppDB adds system metadata around it — an id, ownership, and timestamps — and returns the full document. In the diff below, the + lines are what AppDB adds; everything else is the content you wrote:
Your fields live under content, and queries address them as content.fieldName.

Query Documents

You can filter document using MongoDB query operators like $lt (less than), $gt (greater than), $regex, $jsonSchema and more. For example, if you want to find items you’re running low on, you could run the below query. Replace app.js:
Save. The preview lists Desk (8), Chair (3), and Mouse (5) — the three items under the threshold. See Query Documents for the full filter syntax.

Update a Document

There are three ways to update documents: the single-document replace, the bulk upsert, or the multi-document partial update. The partial update allows you to update only certain fields and each document is updated atomically — meaning updates are forced to take turns on a document, instead of trying to update the same value at the same time. That matters most when writes could collide. To see it in action, simulate a burst of orders: fire ten sales of the same item at the same instant. Each $inc decrements content.qty by one, and because each runs atomically, none overwrite the others. Replace app.js:
Save. The preview shows Notebook remaining: 40 — ten operations, ten decrements, nothing lost. Had you instead read qty into JavaScript, subtracted one, and written the whole document back, all ten reads would have seen the same starting value and overwritten each other, losing almost every sale. Atomic operators eliminate that race. (Re-running the block sells ten more.) See Partially Update Documents for all supported operators.

Aggregate Server-Side

AppDB can group, sum, and sort your data on the server before sending the response — no DataSet refresh, no client-side sorting. This is the same query endpoint used above, extended with aggregation parameters. Replace app.js:
Save. The preview shows totals per category, sorted highest first. See Query Documents for all aggregation parameters, including groupby, sum, avg, and orderby.

Inspect Your Data

To view, query, and edit your collection’s documents outside your app, open AppDB Admin. The Data Explorer lets you run queries and modify documents interactively — useful for checking what your app wrote during development, or for debugging an unexpected query result.

Where to Go Next

This walkthrough covered the core read/write operations — bulk create, query with operators, atomic update, and server-side aggregation. A few more AppDB capabilities are worth exploring:
  • Document-level security — Enforce server-side filter rules on a collection so users see only the documents they’re permitted to access, such as records matching their user ID or group. See Document-Level Security.
  • Collection permissions — Grant specific users, groups, or the app instance itself read, write, or manage access to a collection. See Collection-Level Security.
  • Full endpoint reference — Every AppDB endpoint is listed on the AppDB API Overview.