Value for the business
Use this page when the audience is commercial, executive, or compliance. Pair with The shift-left bet for diagrams and Capability map when diligence starts.
Eelgrass is pre-alpha. This page explains the value thesis. Shipping readiness is always Status.
Cost of bolting on multi-tenancy later
Most databases assume one customer per deployment. SaaS shares one product across many customers. Isolation, migration, and audit work usually stays in the application:
Eelgrass implements those concerns in the engine so the product roadmap can stay on domain features.
Value pillars
1. Isolation is the product default
Customer ask: "Our enterprise deal needs hard separation."
Enterprise isolation is a tenant boundary in the catalog. Fork and suspend are catalog ops. Cross-tenant work uses CDC and app-layer sagas.
2. Compliance and audit without a parallel system
Customer ask: "Show me what this tenant looked like before the incident."
Immutable versioned pages and named snapshots make point-in-time views a storage property. Change feeds (CDC) give downstream systems a durable mutation stream per tenant.
Honest limit today: named-snapshot time travel ships. Long-term compliance packaging and encryption-at-rest enforcement are not shipped yet. See the capability map.
3. Migrations that do not become an ops holiday
Customer ask: "Can we ship schema changes without coordinating 10k customer databases?"
Schemas are versioned code. Tenants apply fingerprints lazily on first touch. Idle tenants cost nothing until they wake up.
4. Environments on demand
Customer ask: "Give support a safe copy of this customer's world."
fork tenant is copy-on-write. Staging and support copies share pages until they diverge.
5. Money that cannot silently lie
Customer ask: "We got burned by floating-point currency bugs."
Money carries minor units and currency in the value. Cross-currency math is a type error. The TypeScript client refuses to treat money as a number.
Competitive framing
| Approach | Isolation | Fleet ops | Audit / PITR | Cross-tenant |
|---|---|---|---|---|
Shared DB + tenant_id | Soft | Easy early | DIY | Too easy (risk) |
| DB-per-tenant | Strong | Hard at scale | Per-DB tooling | Hard (good) / expensive |
| Eelgrass | Engine-native | Engine-native lifecycle | Versioned pages + CDC | Explicit CDC + sagas only |
Do not claim SQL compatibility, drop-in Postgres replacement, or production cloud multi-region today. Differentiation is the tenant model and lifecycle, not query speed versus SQL.
Objection handling
| Objection | Response |
|---|---|
| "We're fine with Postgres RLS." | RLS still puts isolation rules in your app. Eelgrass scopes storage, transactions, forks, and CDC by tenant. |
| "We already run DB-per-tenant." | You already paid for isolation. Eelgrass keeps that boundary and removes the fleet orchestration tax (migrate, fork, restore). |
| "Is it production-ready?" | Pre-alpha. Show Status. Prefer proven capabilities over marketing claims. |
| "What about analytics across tenants?" | Source of truth stays per-tenant. Global views are disposable indexes fed by CDC. |
| "We need EU residency." | The catalog already models residency as a tenant declaration. Control-plane enforcement is later work. |
Who cares inside the buying committee
Next steps for a commercial conversation
- Walk The shift-left bet (five minutes, diagrams).
- Open the playground to try the language in the browser.
- Ground every "we can" in Status and the capability map.
- Send technical evaluators to Consumers and What is Eelgrass?.