What is Transit?

Transit is programmable, versioned data infrastructure for applications. It stores and queries relational tables, key-value state and collaborative documents, and uses durable execution, write-ahead change streams and recorded connectors to activate data—maintaining derived views, driving stateful workflows and coordinating external effects with exact recovery and current authorization.

Start with the data your application needs: its logical schema, physical encoding and collation, how it changes, what computations derive from it, and which policies govern its use. The data model connects these concerns to their supported interfaces, and Internals formalizes the underlying storage, query and execution mechanisms. The local quickstart takes you from an empty installation to a Table you define, query and evolve through the console.

Describe intent and inspect the result

The question that organizes Transit is:

Can someone describe the data, computation and policies they need, then inspect whether Transit is fulfilling that declaration?

For a Table, that means defining columns, keys and defaults, then inspecting its published schema and committed rows. For a query, it means identifying its inputs and computation, then observing a complete result against a specific data basis. For a maintained result, it also means knowing which input changes it includes and whether processing has stopped or is still catching up.

These observations have different meanings. A valid definition may still need publication or activation. An accepted operation may still be running. A complete result describes the source versions it read; newer input can exist. Current permissions govern both execution and inspection.

The product direction is:

Declare your data, the computations that derive from it, and the policies governing its use. Transit manages the storage hierarchy, delta activation and durable execution lifecycle needed to keep those definitions useful.

The supported path is most complete for Tables: create and evolve their schemas, read and change rows, and inspect outcomes through a configured catalog. KV and Documents have client/service APIs, but their SQL declarations compile offline without creating objects. Named captured and maintained relational queries have typed Zig interfaces with explicit host activation and scheduling; SQL view and subscription declarations are unavailable. See the capability map for the boundary between the direction and today's operations.

Work with data

The business stories follow a delivery manager, a reviewer and an operations lead using shared evidence to answer questions, compare branch proposals and respond to meaningful changes. They describe the proposed human/agent collaboration experience and identify its available building blocks separately from capabilities still to be implemented.

Need	Start here
Store records with typed columns, keys and defaults	Tables and schema evolution
Store keys and values under an explicit encoding	KV resources
Accept structured edits and collaborative text with explicit conflicts	Documents
Read, filter, join or aggregate supported sources	SQL and query lifetimes
Control access, retention and resource budgets	Permissions and retention
Inspect definitions, results and progress	Observe the lifecycle
Capture external observations or coordinate external actions	Connectors and recorded outcomes

SQL, language SDKs, HTTP APIs and Board expose different operations over shared owners and contracts. Choose an interface for the data kind, computation lifetime and operations you need. An interface that reads a source does not necessarily create it or maintain a derived result.

Durable execution supports the data lifecycle

In Transit, data and computation are the primary user-facing declarations, while durable processes (Station), write-ahead streams and connectors are the mechanisms that activate changes and preserve progress across failures:

1. Snapshot isolation and atomic publication: Transit records accepted mutations and keeps partially staged data private until its complete successor is published. A reader retains its selected data version while later writes proceed. After an uncertain write, the original operation's recorded outcome tells the caller whether it applied. Repeating SQL creates new work; a lost connection alone does not establish failure.
2. Change capture and derived views: Committed Table transitions preserve ordered row deltas (+row/-row) and schema provenance so change readers, reactive watches and maintained computations can advance from exact source watermarks without polling or losing intermediate transactions.
3. Stateful workflows and external effects: Custom Station workers extend this model with application-defined validation, orchestration and connector calls. A durable process gives that work an identity (PID), ordered input and recoverable progress; its worker can restart without replacing accepted work or re-dispatching an external HTTP/gRPC effect. Processes and turns explain the commit mechanism; build an application explains how to supply your own worker.

Station provides application behaviors and data owners above the generic kernel. Fuze executes vectorized and relational queries over authorized sources. Board presents observed state, and connectors record external attempts and outcomes. These components support the same data and execution boundaries; their architecture and system model explain the division of responsibilities.

Continue from a working dataset

1. Run Transit locally, define a Table and inspect its schema.
2. Read and change its rows from independent console sessions.
3. Use the data model to choose representations, computation lifetimes and policies for your application.
4. Explore workload recipes across languages, then add custom execution or connectors where the application needs them.

Retention defaults to unlimited and requires explicit opt-in to expiry. A name, resource reference or retained snapshot never grants access. The verification reference explains the guarantees and limits behind the supported operations.