The question that decides a build-vs-buy call, answered honestly, per axis, against the code. Caisson runs on plain Next.js and Postgres, bridges to your ORM, takes your auth provider, and hardcodes no infrastructure. Where a backend has a real limit, it is stated here, not hidden.
Each row is what actually ships. The seams are ports you swap (an ORM bridge, an auth provider, a storage backend, an AI lane, an MCP transport) not assumptions baked into the source.
Bring your existing Drizzle or Prisma call sites.
The bridges route your query builder's generated SQL through the fail-closed tenant executor, a rename at the call site, not a schema rewrite or a switch of ORM. Neither adds a runtime dependency on drizzle-orm or @prisma/client; they bridge the query surface, and RLS still enforces isolation underneath.
better-auth out of the box, or your own provider behind one port.
The base depends only on a provider-agnostic SessionProvider port. better-auth is the reference implementation, swap in your own provider without touching the tenancy, billing, or credits packages, which know only the interface.
S3 Object-Lock, Google Cloud Storage, or Cloudflare R2.
One ArtifactStore port, four backends, write-once enforced on each. R2 holds retention at the bucket-lock-rule level rather than per object, the adapter fails closed at construction if the key prefix is not covered by an enabled rule, and refuses a per-object shorten rather than faking it.
OpenRouter, Bedrock, Azure OpenAI, Ollama, and more, behind one gateway.
infer() and embed() resolve a lane to a provider from config, so you swap the model behind the gateway without touching a call site. No provider is hardcoded, and a per-tenant BYOK key resolves ahead of the shared lane.
stdio and Streamable HTTP.
The HTTP transport is stateless per request with mandatory Bearer auth and a DNS-rebinding host allowlist required at construction. Both transports share one transport-agnostic core; there is no SSE transport.
The base substrate's tenant isolation is Postgres row-level security, so the compliance and multi-tenant story is Postgres. But most modules add a capability without pulling in a database of their own. Here is the honest split.
Built on the fail-closed RLS base or the pg-boss job queue, or shipping their own RLS'd Postgres tables (field-crypto's key-version store, alerting's audit trail). Postgres by design, that is where the isolation guarantee lives.
A single SQLite file per tenant (bun:sqlite + sqlite-vec), on the device, no server database, no vector-cloud vendor in the loop.
Crypto, in-process logic, or on-device inference, these add a capability without pulling in a database. They run over a handle you inject or over no store at all.
retention-runner needs Postgres transitively, it schedules through the pg-boss job queue. Browse every module
The deadliest question in a build-vs-buy call is whether it fits the stack you already run. Answer it with code, not a sales call: scaffold the audited base in one command and deploy from the template the generator emits for your host. You own the source from the first line, so a week-one spike is a real evaluation on your own infrastructure — not a demo that disappears.
$ bunx @caisson-sh/cli@latest my-app $ cd my-app $ bun install # ready to run — deploy from the Railway, Fly, or Vercel template