SQL database

Every Remy app ships with its own relational database, and the platform operates all of it. It is isolated per app, migrated on deploy, backed up continuously, and live from the first push. There are no connection strings to manage and no backups to schedule; that work belongs to the platform. What the SDK hands you is the set of verbs an app uses to read and write its data.

That set is complete but deliberately bounded. Because you do not operate this database yourself, the SDK gives you only what an app actually does to its own data: create, read, update, delete, aggregate, and an escape hatch to raw SQL for the rare query the typed API cannot express. The schema is the TypeScript interface you pass to db.defineTable, migrations are diffed and applied for you on deploy, and every row is typed the same from the table to the screen.

Two things shape how you write against it. First, every operation is a network round trip, not a local query, so the cost is round trips, not rows. db.batch collapses several reads and writes into one call, running the writes in order so later reads observe them. Prefer one batched call, or a query shaped to return exactly what a screen needs, over a loop that awaits each row. Second, a db.filter predicate compiles to a SQL WHERE clause, but only when every value it compares against is the row itself or a literal. When it references an input, the current user, or a foreign key gathered earlier, pass that through the bindings argument so the comparison runs in the database instead of pulling the table into memory.

Relationships are a modeling decision you make up front. Embed related data in a JSON column when it is always read and written with its parent; give it its own table, resolved with a second read, only when it is queried independently or grows without bound. There are no JOINs across tables; the SDK reads one table at a time. Every row also carries id, created_at, updated_at, and last_updated_by automatically, so you never declare or set them.