Getting started

Start with the welcome page for the common model: rows, a query, and a result that stays current. Then choose the outcome you need. Each sequence here is independent. You do not need to finish an engine tutorial before building a synced app.

# Choose a starting point

# Browser live views

Start with the browser client chooser. The package name @rindle/client identifies the shared schema, query, store, and view APIs. It does not choose a database or connect to a server by itself.

For client-only tools or a first local experiment:

1. Create a browser store with a TypeScript schema and some rows.
2. Build a query, materialize it, and subscribe to its result.
3. Write a row and observe the updated result.

The standalone @rindle/wasm store is in memory. Your application supplies its rows and manages any persistence or network transport. This setup does not require SQL migrations, named queries, mutators, or an API server.

For server data, choose between a remote result stream, normalized rows with local queries, and optimistic sync. The chooser documents their transport requirements. createRindleClient supplies the complete lease and mutation lifecycle for the standard Rindle API-server and daemon deployment.

The local-only tables guide adds device data to a client that also handles synced data. It is separate from a standalone WASM store.

# Embedded and server views

Use rindle-replica when your Rust application needs a SQLite database and live queries in the same process. You write ordinary SQL through its controlled writer. The runtime captures changes and updates registered queries. No daemon, browser client, or network transport is required.

1. Run the embedded replica example.
2. Start with Db for one owner thread, or choose Cluster for a worker pool.
3. Consume the initial result and subsequent change events.
4. Keep writes on the runtime’s controlled connection so it can capture them.

For Node, the native addon walkthrough exposes the runtime through the TypeScript store API. It requires a repository build; the addon is not part of the public npm release workflow.

# Engine primitives

Use the rindle crate directly when your application owns the data source and can supply each row change. This is useful for custom ingestion, in-memory data, or an integration below the database runtime.

1. Read How it works for sources, the graph, and maintained views.
2. Run the raw engine quickstart.
3. Choose supported Rust query shapes.

The core graph does not observe unrelated SQL writes or provide a network service. The crate map separates these primitives from the embedded runtime.

# SQL service

Use this sequence for a service, script, or ORM that sends ordinary SQL requests.

1. Start a local deployment with the CLI, or provision a Cloud database.
2. Connect the SQL client with the deployment URL and server credential.
3. Apply SQL migrations and run reads or transactions.

SQL-only use does not require a browser client, TypeScript query schema, or optimistic writes. Generate a TypeScript schema when you add typed live queries. Keep database credentials on the server.

# Server read models

Use this sequence for a leaderboard, public page, or API response that reads a maintained result. The consumer can make ordinary requests without subscribing.

1. Connect to a data tier with live-query support.
2. Define a named query and pin its result.
3. Read the result through the API server for each request.

Pins keep results warm with no subscribers. The engine still processes writes that affect them. Initial materialization and result serialization also have a cost. No browser sync, optimistic mutator, or UI framework is required.

# Synced application

Use this sequence for an application with shared data and responsive local writes.

1. Scaffold an app and run it locally.
2. Read the three-tier architecture to understand each component.
3. Change the schema and define queries and fragments.
4. Add mutators and authorize reads and writes.
5. Read the optimistic client guide for synchronization and resource cleanup.

The scaffold uses TanStack Start and includes server rendering. For another framework or an existing project, use the manual quickstart. You can add TanStack integration, preloads, and SSR independently as needed.

Then choose a task guide: pagination, local-only tables, rejected writes, or testing. Use deployment when the application is ready to run outside development.

# PostgreSQL integration

The PostgreSQL source is a preview integration. Read its status, supported types, DDL restrictions, and recovery requirements before planning a deployment.

Postgres remains authoritative. A gateway captures its changes, and Rindle followers maintain live queries over those changes. Your application can keep its existing Postgres writers or use the documented mutator backend.

This integration has a separate setup from Rindle SQL. It is not a connection string change in the standard scaffold.

# Find the next page

Continue with Guides for a task, or Reference for an API, package, or configuration option. The header keeps both sections available from every article. The focused engine and SQL and synced-app lists collect related pages for a longer read.

For an LLM-assisted project, give your assistant Rindle for coding agents and the pages for your chosen integration.