One coordinated schema
PostgreSQL-backed primitives use one Forge-owned schema and bounded pools. A measured hot primitive can use a separate PostgreSQL target without changing the public contract.
Forge runs inside an application backend. It provides key/value storage, queues, pub/sub, blobs, authentication helpers, rate limits, schedules, and configuration through one contract. PostgreSQL is the shared durable backend; memory is the process-local test backend. Blob bytes may also use a filesystem or S3-compatible store.
The application owns its HTTP or RPC framework, business tables, authorization policy, worker handlers, deployment, process signals, and telemetry export. Frontend frameworks, browser transports, client caches, WebSockets, SSE clients, and refetching are also application concerns. Forge ships no browser package.
One coordinated schema
PostgreSQL-backed primitives use one Forge-owned schema and bounded pools. A measured hot primitive can use a separate PostgreSQL target without changing the public contract.
One contract in four languages
Rust, JavaScript, Python, and Go are checked against one versioned contract and the same declarative conformance scenarios.
Explicit backend differences
Memory and PostgreSQL implement the same supported operations, while runtime capabilities report durability, process scope, notification, and blob differences.
Application-owned integration
Forge does not install a web server, signal handler, metrics exporter, MCP server, or frontend adapter. The host application owns those boundaries.
[postgres]url = "${DATABASE_URL:-postgres://localhost/myapp}"init() reads forge.toml and returns one client. Development may run Forge migrations during initialization. Production startup validates the schema by default; run migrations as a separate deployment step before serving traffic.