Database

any is a document database that lives on your device, syncs through an end-to-end-encrypted network, and merges concurrent edits with CRDTs. This section covers the data model and the HTTP surface for reading and writing it.

The model in one picture

account
 └── space                      encrypted, shared with members
      ├── objects               one row per object: its property values
      │     └── object          one type in any.type, N collections in any.collections
      │           ├── properties     record[ownerId][propId]
      │           └── datasets       chat_messages, editor_blocks, <runtime>…
      ├── types                 property definitions + parts + layout
      └── collections           property definitions only

• A space is the unit of sharing and encryption. Every member holds the same data; every write is a change in a per-object DAG that syncs to everyone.
• An object is a document. It has exactly one type in any.type, any number of collections in any.collections, property values keyed by <ownerId>.<propId> — the owner being the type or one of the collections — and any number of per-object datasets (records that belong to that object — chat messages, editor blocks, or a runtime dataset you declare).
• A type is what an object is: property definitions (kind, descriptor, scope), a layout, and parts — display units owning datasets a module serves: records (a runtime schema), editor (a block body), chat (a conversation). The hidden built-in types page and dataview exist in every space; your own document types are registered as bundles, and the space's chat is installed by the server's catalog.
• A collection is what an object is filed under: property definitions and nothing else. miniapp (the sidebar) and bin are built in; the wiki and the contact facets come from the catalog.

One read path, many write paths

Reads always go through the windowed query primitive: POST /v1/spaces/:spaceId/objects/query for the cross-object objects storage collection and POST /v1/spaces/:spaceId/query for one object's dataset. Each has a /subscribe twin that returns the same snapshot plus a live stream of changes (see Subscribe). Writes go through purpose-built endpoints — property set, generic /modify, and the modules' own handlers — and each returns the same {versionId, changeId, recordIds} receipt; object create answers with the new objectId.

Why it matters. There is no server between you and your data. Queries run against a local any-store database, so a read is a local disk read, a write is immediately visible, and both work offline. Sync and merge happen underneath — the query you ran a second ago keeps answering while peers catch up.

Where to start

1. Spaces — create one, read its metadata, understand its lifecycle.
2. Objects — create objects with a type, file them under collections, delete them.
3. Types and properties — define the shape of your data.
4. Collections — file objects under facets that add columns.
5. Reading data — the filter grammar, sort, paging.
6. Writing data — property writes, /modify ops, the write receipt.