chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Database backups and restore"
|
||||
description: "Create manual database backups, restore snapshots from the InsForge dashboard, and use automated daily backups on InsForge Cloud with 7-day retention."
|
||||
---
|
||||
|
||||
Back up and restore your database from **Database → Backup & Restore** in the dashboard. InsForge Cloud also backs up your project automatically every day, so you always have a recent copy to roll back to.
|
||||
|
||||
Backups cover the database only — files uploaded to Storage are not included.
|
||||
|
||||
<Frame caption="Here is where it lives in the UI: Database → Backup & Restore.">
|
||||
<img src="/images/dashboard-backup-restore.png" alt="InsForge dashboard Backup & Restore page showing manual backups and scheduled backups with a Restore button" />
|
||||
</Frame>
|
||||
|
||||
## Scheduled backups
|
||||
|
||||
InsForge Cloud takes a full backup of every active project on a paid plan once a day, retained for 7 days. The **Scheduled Backups** list shows when each backup expires, and any of them can be restored at any time. Manual backups don't affect the daily schedule.
|
||||
|
||||
## Manual backups
|
||||
|
||||
Click **Create a Backup** before a risky change and optionally give it a name. The backup runs in the background; the list shows its status, size, and creation time, and lets you rename or delete it. The Free plan includes 1 manual backup slot, paid plans include 5, and manual backups are kept until you delete them.
|
||||
|
||||
## Restore
|
||||
|
||||
Click **Restore** next to any completed backup — scheduled or manual. Restoring replaces the current database with the backup: the project is offline during the restore, data created after the backup is lost, and the action can't be undone, so take a manual backup first if you're unsure.
|
||||
|
||||
## Self-hosting
|
||||
|
||||
Self-hosted deployments have the same **Backup & Restore** page for manual backups and restores. Backups are stored alongside your project's storage (local disk, or your S3 bucket when configured) and kept until you delete them. The official Docker image needs no extra setup.
|
||||
|
||||
## More resources
|
||||
|
||||
- [Database overview](/core-concepts/database/overview) for how the database is exposed to your app.
|
||||
- [Database migrations](/core-concepts/database/migrations) to version schema changes instead of restoring to undo them.
|
||||
- [Database branching](/agent-native/branching) to rehearse risky changes on a copy.
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Database migrations"
|
||||
description: "Track schema changes in git and apply them with the InsForge CLI"
|
||||
---
|
||||
|
||||
Migrations are versioned SQL files in `migrations/` applied with `@insforge/cli`. Each successful run is recorded in `system.custom_migrations`. The workflow is forward-only.
|
||||
|
||||
## Concepts
|
||||
|
||||
A migration is one SQL file prefixed with a 14-digit UTC timestamp: `<YYYYMMDDHHmmss>_<name>.sql`. The CLI applies pending files in order inside a transaction, sets `search_path` to `public`, and records history only on success. PostgREST reloads schema metadata automatically. `BEGIN`/`COMMIT`/`ROLLBACK` inside a file are rejected.
|
||||
|
||||
## Usage
|
||||
|
||||
Link the backend, then create a file.
|
||||
|
||||
```bash
|
||||
npx @insforge/cli login
|
||||
npx @insforge/cli link
|
||||
npx @insforge/cli db migrations new create-employees-table
|
||||
```
|
||||
|
||||
Write the SQL.
|
||||
|
||||
```sql
|
||||
create table if not exists public.employees (
|
||||
id bigint primary key generated always as identity,
|
||||
name text not null,
|
||||
email text,
|
||||
created_at timestamptz default now()
|
||||
);
|
||||
```
|
||||
|
||||
Apply pending migrations and check history.
|
||||
|
||||
```bash
|
||||
npx @insforge/cli db migrations up --all
|
||||
npx @insforge/cli db migrations list
|
||||
```
|
||||
|
||||
Target a single file with `up <version>`, or apply everything pending up to and including a target with `up --to <version>`.
|
||||
|
||||
## Specific usage cases
|
||||
|
||||
Adopting migrations on an existing project: run `db migrations fetch` first to materialize remote history into local files. Once applied remotely, never edit a migration in place. Write a forward migration instead.
|
||||
|
||||
Once you opt in, route all schema changes through files. Ad hoc dashboard edits cause drift between git and `system.custom_migrations`.
|
||||
|
||||
## More resources
|
||||
|
||||
- [Database branching](/agent-native/branching) to rehearse a migration on a copy.
|
||||
- [Database overview](/core-concepts/database/overview) for how PostgREST picks up schema changes.
|
||||
- [PostgreSQL DDL docs](https://www.postgresql.org/docs/15/ddl.html) for the SQL you write.
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: "Database"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Use InsForge to manage your data."
|
||||
---
|
||||
|
||||
Every InsForge project comes with a full [Postgres](https://www.postgresql.org/) database. Every table is automatically a typed REST and SDK endpoint. Auth tokens scope every read and write through row-level security. The same Postgres handles relational queries, semantic search via pgvector, and realtime change feeds.
|
||||
|
||||
<Frame caption="The table editor: typed columns, inline editing, CSV import, and a SQL studio.">
|
||||
<img src="/images/database-table-editor.png" alt="InsForge dashboard table editor showing a messages table with typed columns" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
**Looking for file storage?** Use [Storage](/core-concepts/storage/overview) for images, PDFs, and other binary content. The database stores rows; storage stores objects.
|
||||
</Note>
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
Client[Client Application] --> SDK[InsForge SDK]
|
||||
SDK --> API[InsForge API]
|
||||
API --> PostgREST[PostgREST v12.2]
|
||||
PostgREST --> PG[(PostgreSQL 15)]
|
||||
API --> PG
|
||||
|
||||
PG --> RLS[Row Level Security]
|
||||
PG --> Triggers[Database Triggers]
|
||||
PG --> Functions[Stored Functions]
|
||||
PG --> Schemas[Multiple Schemas]
|
||||
|
||||
style Client fill:#1e293b,stroke:#475569,color:#e2e8f0
|
||||
style SDK fill:#1e40af,stroke:#3b82f6,color:#dbeafe
|
||||
style API fill:#166534,stroke:#22c55e,color:#dcfce7
|
||||
style PostgREST fill:#c2410c,stroke:#fb923c,color:#fed7aa
|
||||
style PG fill:#0e7490,stroke:#06b6d4,color:#cffafe
|
||||
style RLS fill:#4c1d95,stroke:#8b5cf6,color:#ede9fe
|
||||
style Triggers fill:#4c1d95,stroke:#8b5cf6,color:#ede9fe
|
||||
style Functions fill:#4c1d95,stroke:#8b5cf6,color:#ede9fe
|
||||
style Schemas fill:#4c1d95,stroke:#8b5cf6,color:#ede9fe
|
||||
```
|
||||
|
||||
## Features
|
||||
|
||||
### Tables as APIs
|
||||
|
||||
Define a table and you immediately get REST endpoints plus a typed SDK client for it. No code generation step. The auth JWT scopes every query through RLS.
|
||||
|
||||
### Migrations
|
||||
|
||||
Track and apply SQL changes in order. [Migrations](/core-concepts/database/migrations) ship as plain `.sql` files in your repo, applied with `npx @insforge/cli db migrations up --all` or via the MCP tool.
|
||||
|
||||
### Branching
|
||||
|
||||
Spin up an isolated database branch to test risky schema changes against a copy of production data. See [Branching](/agent-native/branching).
|
||||
|
||||
### pgvector
|
||||
|
||||
Native vector search for embeddings, with HNSW and IVFFlat indexes. See [pgvector](/core-concepts/database/pgvector).
|
||||
|
||||
### Row-level security
|
||||
|
||||
Postgres RLS policies enforce access at the row level. Policies read the auth JWT, so the same rule applies to REST queries, SDK calls, realtime subscriptions, and storage requests.
|
||||
|
||||
## Concepts
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Migrations" icon="layer-group" href="/core-concepts/database/migrations">
|
||||
Apply SQL changes in order, safely.
|
||||
</Card>
|
||||
<Card title="Branching" icon="code-branch" href="/agent-native/branching">
|
||||
Isolated databases for preview and risky changes.
|
||||
</Card>
|
||||
<Card title="pgvector" icon="brain" href="/core-concepts/database/pgvector">
|
||||
Vector search for embeddings.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Build with it
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="TypeScript SDK" icon="js" href="/sdks/typescript/database">
|
||||
Typed queries, inserts, and updates from Node, browser, and edge.
|
||||
</Card>
|
||||
|
||||
<Card title="Swift SDK" icon="swift" href="/sdks/swift/database">
|
||||
Native Swift database client for iOS and macOS.
|
||||
</Card>
|
||||
|
||||
<Card title="Kotlin SDK" icon="android" href="/sdks/kotlin/database">
|
||||
Coroutines-first database client for Android and JVM.
|
||||
</Card>
|
||||
|
||||
<Card title="REST API" icon="code" href="/sdks/rest/database">
|
||||
Plain HTTP database endpoints, callable from any language.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Next steps
|
||||
|
||||
- Set up the [CLI](/quickstart) to link your project (the recommended path).
|
||||
- Browse the [TypeScript SDK reference](/sdks/typescript/database) for typed queries.
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: "pgvector"
|
||||
description: "Store embeddings and run similarity search inside Postgres"
|
||||
---
|
||||
|
||||
[pgvector](https://github.com/pgvector/pgvector) ships on every InsForge project. Use it for semantic search, recommendations, and [RAG](https://www.pinecone.io/learn/retrieval-augmented-generation/).
|
||||
|
||||
## Prompt your agent
|
||||
|
||||
> Add pgvector to my project. Create a `documents` table with `content` and a 1536-dim `embedding` column, plus an HNSW cosine index. When I insert content, embed it with OpenRouter's `text-embedding-3-small` from a server-side route. Expose a `match_documents(query, count, threshold)` RPC that returns top similarity matches.
|
||||
|
||||
## Concepts
|
||||
|
||||
A vector is a list of numbers representing an item. Two vectors are similar if they sit close in vector space. Store the vector next to its row, embed the user query the same way, and pgvector ranks by distance.
|
||||
|
||||
## Usage
|
||||
|
||||
Enable the extension and create a vector column. Match the dimension to your model (`text-embedding-3-small` is 1536).
|
||||
|
||||
```sql
|
||||
create extension if not exists vector;
|
||||
|
||||
create table documents (
|
||||
id bigserial primary key,
|
||||
content text,
|
||||
embedding vector(1536)
|
||||
);
|
||||
```
|
||||
|
||||
Generate an embedding server-side and insert it.
|
||||
|
||||
```typescript
|
||||
import OpenAI from 'openai';
|
||||
import { createClient } from '@insforge/sdk';
|
||||
|
||||
const openai = new OpenAI({
|
||||
baseURL: 'https://openrouter.ai/api/v1',
|
||||
apiKey: process.env.OPENROUTER_API_KEY,
|
||||
});
|
||||
const insforge = createClient({ projectId: process.env.INSFORGE_PROJECT_ID });
|
||||
|
||||
const { data } = await openai.embeddings.create({
|
||||
model: 'openai/text-embedding-3-small',
|
||||
input: 'hello world',
|
||||
});
|
||||
|
||||
await insforge.database.from('documents').insert({
|
||||
content: 'hello world',
|
||||
embedding: data[0].embedding,
|
||||
});
|
||||
```
|
||||
|
||||
Query by cosine distance (`<=>`). L2 (`<->`) and inner product (`<#>`) are also available.
|
||||
|
||||
```sql
|
||||
select id, content
|
||||
from documents
|
||||
order by embedding <=> $1
|
||||
limit 5;
|
||||
```
|
||||
|
||||
## Specific usage cases
|
||||
|
||||
Wrap search in a Postgres function and call it via `rpc()` to keep the math server-side:
|
||||
|
||||
```sql
|
||||
create or replace function match_documents(
|
||||
query_embedding vector(1536),
|
||||
match_count int default 5,
|
||||
match_threshold float default 0
|
||||
)
|
||||
returns table (id bigint, content text, similarity float)
|
||||
language sql stable
|
||||
as $$
|
||||
select id, content, 1 - (embedding <=> query_embedding) as similarity
|
||||
from documents
|
||||
where 1 - (embedding <=> query_embedding) > match_threshold
|
||||
order by embedding <=> query_embedding
|
||||
limit match_count;
|
||||
$$;
|
||||
```
|
||||
|
||||
Past ~10k rows, add an HNSW index:
|
||||
|
||||
```sql
|
||||
create index on documents using hnsw (embedding vector_cosine_ops);
|
||||
```
|
||||
|
||||
## More resources
|
||||
|
||||
- [pgvector on GitHub](https://github.com/pgvector/pgvector) for operators and indexes.
|
||||
- [OpenRouter embeddings](https://openrouter.ai/docs/features/multimodal/embeddings) for the model catalog.
|
||||
- [Model Gateway overview](/core-concepts/ai/overview) for the InsForge side of OpenRouter.
|
||||
Reference in New Issue
Block a user