top companies

{
  "id": "P09-C-001",
  "evidence_class": "observed",
  "source": "https://neon.com/docs/guides/multitenancy",
  "observed": "2026-08-27",
  "name": "Neon",
  "category": "managed-postgres",
  "claim": "Neon documents three tenancy patterns (database-per-user, schema-per-user, shared schema) and explicitly recommends project-per-tenant: 'We recommend setting up one project per user, rather than, for example, using a branch per customer.' Projects provision in milliseconds and idle ones are 'virtually free' via scale-to-zero. TOP10: this is the only Postgres surface where per-tenant physical isolation is economically free at rest, which is exactly the shape a host needs when absorbing donor systems that each want their own database.",
  "tenancy_model": "db-per-tenant (project-per-tenant recommended); schema-per-tenant and RLS also supported",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "Page gives no numeric cap on projects/branches per account; 'generous number' is unquantified. Scale-to-zero cold start not quantified on this page.",
  "disposition": "top10"
}

{
  "id": "P09-C-002",
  "evidence_class": "observed",
  "source": "https://developers.cloudflare.com/d1/platform/limits/",
  "observed": "2026-08-27",
  "name": "Cloudflare D1",
  "category": "embedded-edge-sql",
  "claim": "D1 allows 50,000 databases per account on Workers Paid (10 free), with a footnote that paid plans can request 'millions to tens-of-millions of databases (or more) per account'. Docs state D1 'is designed for horizontal scale out across multiple, smaller (10 GB) databases, such as per-user, per-tenant or per-entity databases' at no extra cost since billing is queries+storage only. TOP10: proves database-per-tenant at a cardinality no Postgres surface matches, and prices tenancy at zero.",
  "tenancy_model": "db-per-tenant (explicitly designed for it)",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "Hard 10 GB per-database ceiling that 'cannot be further increased'. Single-threaded per DB: ~1,000 qps at 1ms queries, ~10 qps at 100ms. 100 columns/table, 2 MB max row, ~5,000 DB bindings per Worker.",
  "disposition": "top10"
}

{
  "id": "P09-C-003",
  "evidence_class": "observed",
  "source": "https://developers.cloudflare.com/durable-objects/platform/pricing/",
  "observed": "2026-08-27",
  "name": "Cloudflare Durable Objects",
  "category": "embedded-edge-actor",
  "claim": "Each SQLite-backed Durable Object is a uniquely addressable actor bundling compute with its own private embedded SQLite DB, giving a single-threaded serialization point per entity without external locking. Idle objects are evicted and 'Inactive objects receiving no requests do not incur any duration charges'; an empty DB costs ~12 KB. TOP10: this is the cleanest commercial precedent for per-tenant state that is also a per-tenant compute/coordination boundary, which a federating host needs for donor-app session and lock state.",
  "tenancy_model": "object-per-tenant/per-entity (actor model, private SQLite per object)",
  "workload_shapes": [
    "transactional",
    "cache",
    "sync"
  ],
  "limitations": "Duration billed at 128 MB per object regardless of real memory. WebSocket-heavy designs cost ~20x more without the Hibernation API ($419/mo vs $20.65/mo in Cloudflare's own examples). Every write including deletes and setAlarm() counts as billable row writes. SQLite storage billing began ~2026-01-07.",
  "disposition": "top10"
}

{
  "id": "P09-C-004",
  "evidence_class": "observed",
  "source": "https://turso.tech/pricing",
  "observed": "2026-08-27",
  "name": "Turso",
  "category": "embedded-edge-sql",
  "claim": "Turso prices for the many-database pattern: 100 databases on Free and 'Unlimited' on Developer ($4.99/mo), Scaler ($24.92/mo) and Pro ($416.58/mo), metering row reads (500M free to 250B on Pro) and row writes (10M free to 250M on Pro) rather than database count. Its Partner Program references companies 'helping companies adopt the many-database architecture'.",
  "tenancy_model": "db-per-tenant (unlimited DBs on paid tiers)",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "Pricing page never uses the words database-per-tenant/per-user, so that framing is partly inferred from the unlimited-DB allowance plus partner copy. Row-based metering means a chatty donor app can cost far more than its data size suggests.",
  "disposition": "register"
}

{
  "id": "P09-C-005",
  "evidence_class": "observed",
  "source": "https://makerkit.dev/blog/tutorials/supabase-rls-best-practices",
  "observed": "2026-08-27",
  "name": "Supabase",
  "category": "managed-postgres-baas",
  "claim": "Supabase is the reference implementation of RLS-based tenancy: shared tables with a tenant_id column and Postgres row-level security policies, with the client automatically attaching the authenticated user's JWT so policies enforce isolation below the application layer. Prevailing guidance is shared-DB+RLS as default, reserving DB-per-tenant for compliance-bound enterprise tenants. TOP10: establishes the baseline the host must beat or adopt, and shows tenancy enforced in the database rather than in app code.",
  "tenancy_model": "row-level (RLS + tenant_id) default; schema-per-tenant supported; db-per-tenant for enterprise",
  "workload_shapes": [
    "transactional",
    "files",
    "search",
    "vector"
  ],
  "limitations": "Does not scale to zero on Pro, so idle tenants still pay compute. Egress metered at $0.09/GB. Enabling RLS on an existing production table without policies breaks the app; sequencing is a real migration hazard.",
  "disposition": "top10"
}

{
  "id": "P09-C-006",
  "evidence_class": "observed",
  "source": "https://raw.githubusercontent.com/supabase/supabase/master/LICENSE",
  "observed": "2026-08-27",
  "name": "Supabase (OSS core licence)",
  "category": "licence-check",
  "claim": "Read the LICENSE body directly rather than trusting a badge: supabase/supabase is Apache-2.0 on the master branch (the main branch returns 404), and the supabase/postgres image carries The PostgreSQL License. This is a genuinely permissive core, unlike several sync/streaming peers surveyed here.",
  "tenancy_model": "n/a (licence finding)",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "Apache-2.0 covers the repo; individual components in the Supabase org may carry different terms and were not each checked. Managed-platform features are not necessarily in the OSS repo.",
  "disposition": "register"
}

{
  "id": "P09-C-007",
  "evidence_class": "observed",
  "source": "https://raw.githubusercontent.com/get-convex/convex-backend/main/LICENSE.md",
  "observed": "2026-08-27",
  "name": "Convex",
  "category": "sync-reactive-backend",
  "claim": "Convex is a reactive document database where queries are subscriptions. Critically, the LICENSE body is 'Functional Source License, Version 1.1, Apache 2.0 Future License' (FSL-1.1-Apache-2.0), NOT an OSI licence: any 'Competing Use' making the software available in a product that substitutes for Convex is prohibited, converting to Apache-2.0 later. TOP10: a host foundation that resold a Convex-derived backend would be a textbook Competing Use, so this is a licence landmine to name explicitly.",
  "tenancy_model": "deployment-per-app/per-environment; no documented tenant primitive inside a deployment",
  "workload_shapes": [
    "document",
    "sync",
    "workflow"
  ],
  "limitations": "GitHub API reports the licence as NOASSERTION, so any tooling that reads the API field would miss the FSL restriction entirely. Convex pricing page does not state the data model, sync mechanism, or licence; those required reading the repo.",
  "disposition": "top10"
}

{
  "id": "P09-C-008",
  "evidence_class": "observed",
  "source": "https://www.convex.dev/pricing",
  "observed": "2026-08-27",
  "name": "Convex (commercial tiers)",
  "category": "sync-reactive-backend",
  "claim": "Convex prices per developer seat plus resources: Free/Starter at $0, Professional at $25 per developer/month, Business & Enterprise at a $2,500 monthly minimum. Included resources on Free/Pro: 1M/25M function calls, 0.5/50 GB database storage, 1/100 GB file storage, 1/50 GB egress.",
  "tenancy_model": "per-deployment, seat-priced",
  "workload_shapes": [
    "document",
    "sync",
    "workflow"
  ],
  "limitations": "Seat-based pricing is a poor fit for a host with many low-value tenants; the $2,500 Business floor is steep. Concurrency caps (1,000 sessions Free, 10,000 Pro) bound tenant fan-out per deployment.",
  "disposition": "register"
}

{
  "id": "P09-C-009",
  "evidence_class": "observed",
  "source": "https://electric.ax/docs/guides/auth",
  "observed": "2026-08-27",
  "name": "ElectricSQL",
  "category": "sync-local-first",
  "claim": "Electric syncs 'Shapes' (filtered table views fetched over plain HTTP via GET /v1/shape) and deliberately does NOT enforce row-level security itself: 'you don't have to codify your auth logic into a database rule system.' Tenancy is enforced by a proxy or gatekeeper that sets the table and WHERE clause server-side, and client-supplied subset queries are AND-ed so they 'can only narrow results, never widen them.' TOP10: this is the strongest architectural precedent for a host that must federate donor stores it does not control, since authorization lives above the database rather than inside each donor's schema.",
  "tenancy_model": "proxy/gatekeeper-enforced row scoping (shape WHERE clause), not in-database RLS",
  "workload_shapes": [
    "sync",
    "transactional"
  ],
  "limitations": "Read-path only: writes are the application's responsibility. Conflict handling is last-write-wins and not customizable. Offline is explicitly out of scope since Electric does not own client-side persistence. Cache isolation depends on getting Vary: Authorization headers right.",
  "disposition": "top10"
}

{
  "id": "P09-C-010",
  "evidence_class": "observed",
  "source": "https://api.github.com/repos/electric-sql/electric",
  "observed": "2026-08-27",
  "name": "ElectricSQL (licence)",
  "category": "licence-check",
  "claim": "electric-sql/electric is Apache-2.0 (SPDX confirmed via GitHub API, ~10.3k stars), making it one of only two genuinely permissive sync engines in this survey and the safest to embed in a commercial host foundation.",
  "tenancy_model": "n/a (licence finding)",
  "workload_shapes": [
    "sync"
  ],
  "limitations": "SPDX field read from the API rather than the LICENSE body; API-reported SPDX proved unreliable for Convex/PowerSync/Inngest, so a body read is still advisable before commitment.",
  "disposition": "register"
}

{
  "id": "P09-C-011",
  "evidence_class": "observed",
  "source": "https://raw.githubusercontent.com/powersync-ja/powersync-service/main/LICENSE",
  "observed": "2026-08-27",
  "name": "PowerSync",
  "category": "sync-local-first",
  "claim": "PowerSync syncs a server subset into a full local SQLite, giving genuine offline support, with writes uploaded through your own API. Its server LICENSE body is 'Functional Source License, Version 1.1, ALv2 Future License' (FSL-1.1-ALv2): source-available, not OSI, barring Competing Use, converting to Apache-2.0 two years after release. Client SDKs are Apache-2.0/MIT.",
  "tenancy_model": "per-user/per-tenant sync rules defining the synced subset; backend DB keeps its own tenancy",
  "workload_shapes": [
    "sync",
    "transactional"
  ],
  "limitations": "GitHub API reports NOASSERTION, hiding the FSL. The split licence (permissive clients, FSL server) means 'PowerSync is open source' is true only of the half you do not host.",
  "disposition": "register"
}

{
  "id": "P09-C-012",
  "evidence_class": "observed",
  "source": "https://api.github.com/repos/rocicorp/mono",
  "observed": "2026-08-27",
  "name": "Zero (Rocicorp)",
  "category": "sync-local-first",
  "claim": "Zero (rocicorp/mono, Apache-2.0 confirmed via SPDX, ~3.4k stars, tagline '99% of Queries in Zero Milliseconds') is a server-authoritative bidirectional sync engine: the server accepts or rejects each mutation, which is the correct trust posture for a host that cannot let donor clients write authoritatively.",
  "tenancy_model": "server-authoritative mutations; query-level scoping, no distinct tenant primitive observed",
  "workload_shapes": [
    "sync",
    "transactional"
  ],
  "limitations": "Early stage with breaking changes between versions and a React-centric ecosystem. Offline is stated to be out of scope for now. Reads come from an IndexedDB cache rather than a full local SQL store.",
  "disposition": "register"
}

{
  "id": "P09-C-013",
  "evidence_class": "observed",
  "source": "https://developers.cloudflare.com/r2/pricing/",
  "observed": "2026-08-27",
  "name": "Cloudflare R2",
  "category": "object-storage",
  "claim": "R2 is S3-compatible with 'no charges for egress bandwidth for any storage class', billing only storage plus Class A (mutating, up to $9.00/million) and Class B (reading, $0.36-$0.90/million) operations, with Infrequent Access adding $0.01/GB retrieval. Register rationale: for a host federating donor systems, egress is the tax that scales with the number of systems you bridge, and R2 removes it outright.",
  "tenancy_model": "bucket-per-tenant or prefix-per-tenant (both viable); no built-in tenant primitive",
  "workload_shapes": [
    "files"
  ],
  "limitations": "Usage rounds up to the next billing unit. Object storage carries no query or tenancy semantics, so isolation is entirely a naming/credential discipline the host must impose.",
  "disposition": "register"
}

{
  "id": "P09-C-014",
  "evidence_class": "observed",
  "source": "https://www.cloudflare.com/developer-platform/products/r2/",
  "observed": "2026-08-27",
  "name": "Cloudflare R2 (migration path)",
  "category": "object-storage",
  "claim": "R2 supports progressive migration by sitting in front of a legacy S3 bucket and copying objects on demand as requested, avoiding a large upfront migration. This is directly analogous to the strangler pattern a host needs when absorbing a donor system's existing file store.",
  "tenancy_model": "n/a (migration mechanism)",
  "workload_shapes": [
    "files"
  ],
  "limitations": "Page omits per-GB storage and Class A/B rates entirely; those had to be read from the separate pricing doc.",
  "disposition": "register"
}

{
  "id": "P09-C-015",
  "evidence_class": "observed",
  "source": "https://aws.amazon.com/rds/aurora/pricing/",
  "observed": "2026-08-27",
  "name": "AWS Aurora",
  "category": "managed-postgres",
  "claim": "Aurora Serverless v2 bills per second in 0.5 ACU increments and lists 'Starting capacity: 0 ACU' (scale to zero), at roughly $0.12/ACU-hour Standard or $0.156 I/O-Optimized. Aurora Limitless Database (PostgreSQL only) distributes writes across multiple writer instances while preserving a single-database experience.",
  "tenancy_model": "schema-per-tenant or RLS within a cluster; cluster-per-tenant only for premium tenants",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "Minimum configurable capacity is 0.5 ACU even though starting capacity is listed as 0. I/O-Optimized storage costs ~$0.225/GB-month vs ~$0.10 Standard and only wins when I/O exceeds ~25% of Aurora spend. Reserved Instances need ~30% more purchased to keep discounts on I/O-Optimized.",
  "disposition": "register"
}

{
  "id": "P09-C-016",
  "evidence_class": "observed",
  "source": "https://planetscale.com/docs/postgres/pricing",
  "observed": "2026-08-27",
  "name": "PlanetScale",
  "category": "managed-postgres-mysql",
  "claim": "PlanetScale removed its free Hobby tier in April 2024 and has not restored it; entry is a $5/month PS-5 single-node Postgres cluster, HA is ~3x single-node, and Vitess MySQL starts at $39/month for 3-node HA. Sharded keyspaces are creatable on any plan; Postgres sharding is not Vitess but a separate project (Neki).",
  "tenancy_model": "keyspace/shard-per-tenant via Vitess vindex (MySQL); tenant_id sharding key",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "Vitess sharding does not apply to their Postgres offering yet. One aggregator (costbench) still claims a free tier exists, which contradicts PlanetScale's own docs and multiple sources; treat third-party pricing aggregators as unreliable. Pricing verified via search summary of the docs page rather than a direct page read.",
  "disposition": "register"
}

{
  "id": "P09-C-017",
  "evidence_class": "observed",
  "source": "https://www.mongodb.com/docs/atlas/reference/atlas-limits/",
  "observed": "2026-08-27",
  "name": "MongoDB Atlas",
  "category": "document",
  "claim": "Atlas has no hard collection cap but recommends maxima counting collections AND indexes together: 5,000 (M10), 10,000 (M20/M30), 100,000 (M40+); exceeding them slows checkpoints and can stall operations. TOP10: this is the clearest quantified proof that collection-per-tenant and database-per-tenant have a hard economic ceiling in the document world, forcing shared-collection tenant discriminators at scale.",
  "tenancy_model": "shared collection with tenantId discriminator at scale; collection-/db-per-tenant only in the low thousands",
  "workload_shapes": [
    "document",
    "search",
    "vector"
  ],
  "limitations": "A tenant with 5 indexes consumes ~6 units, capping M40+ at roughly 16,000 tenants. 100 database users per project blocks user-per-tenant beyond 100. 25 clusters/project and 250 projects/org bound cluster-per-tenant. Atlas Search caps at 2,500 indexes per cluster, so search-index-per-tenant is severely constrained.",
  "disposition": "top10"
}

{
  "id": "P09-C-018",
  "evidence_class": "observed",
  "source": "https://firebase.google.com/docs/firestore/quotas",
  "observed": "2026-08-27",
  "name": "Google Firestore",
  "category": "document",
  "claim": "Firestore enforces a hard 'Maximum number of databases per project: 100' (increase only via support request), and CMEK databases default to a quota of 0 behind an allowlist. This makes database-per-tenant structurally unavailable on Firestore, pushing all tenancy into collection paths plus Security Rules.",
  "tenancy_model": "path-based partitioning enforced by Security Rules; db-per-tenant capped at 100",
  "workload_shapes": [
    "document",
    "sync"
  ],
  "limitations": "Facts extracted from the rendered quotas page via text scrape rather than an interactive read. Per-document write-rate limits were not isolated in the extraction and remain unverified here.",
  "disposition": "register"
}

{
  "id": "P09-C-019",
  "evidence_class": "observed",
  "source": "https://docs.fauna.com/fauna/current/eol-faq/",
  "observed": "2026-08-27",
  "name": "Fauna",
  "category": "document",
  "claim": "LIVE NEGATIVE FINDING: Fauna is dead. The service ended 30 May 2025 at 12:00 Pacific, after which all accounts and associated data were permanently deleted; the company cited an inability to raise the capital needed to run a global operational database. Reported impact: 195+ databases and 3,000+ development teams. Any Actionist design doc listing Fauna as a candidate is out of date.",
  "tenancy_model": "n/a (service terminated)",
  "workload_shapes": [
    "document",
    "transactional"
  ],
  "limitations": "Shutdown facts gathered from the EOL FAQ plus contemporaneous InfoWorld/InfoQ/Register coverage via search rather than a direct fetch of the FAQ page. Promised open-sourcing of FQL was announced as an intent; current status unverified.",
  "disposition": "rejected"
}

{
  "id": "P09-C-020",
  "evidence_class": "observed",
  "source": "https://clickhouse.com/pricing",
  "observed": "2026-08-27",
  "name": "ClickHouse Cloud",
  "category": "analytics",
  "claim": "ClickHouse Cloud is usage-based with compute and storage scaled independently and explicitly 'automatically scale unused resources down to zero so that you don't pay for idle services', plus configurable autoscaling limits to cap runaway query spend. The OSS engine is Apache-2.0 (confirmed via GitHub SPDX, ~49.5k stars).",
  "tenancy_model": "service-per-environment; tenant scoping is a query/row concern, no built-in tenant primitive observed",
  "workload_shapes": [
    "analytics"
  ],
  "limitations": "Pricing page states no tier names, no minimum spend and no per-unit rates, deferring to sales; the Apache-2.0 licence claim comes from the repo, not the pricing page which omits it.",
  "disposition": "register"
}

{
  "id": "P09-C-021",
  "evidence_class": "observed",
  "source": "https://www.tinybird.co/pricing",
  "observed": "2026-08-27",
  "name": "Tinybird",
  "category": "analytics",
  "claim": "Tinybird is managed ClickHouse that turns SQL into REST endpoints, priced Free / Developer ($49-mo, page also shows 'Starting at $25/month') / SaaS / Enterprise, with vCPU overage at $0.0002/second and storage at $0.058/GB. JWT support on all paid tiers is the mechanism for per-tenant API scoping. Register rationale: it is the clearest commercial pattern for handing an analytics slice to a tenant's browser without exposing the warehouse, which a host needs when donor apps must show their owners metrics.",
  "tenancy_model": "JWT-scoped tokens per tenant over shared data sources; unlimited workspaces",
  "workload_shapes": [
    "analytics"
  ],
  "limitations": "Row-level scoping mechanics are not detailed on the pricing page, so the per-tenant enforcement claim is partly inferred from the JWT/Tokens API line items. Developer tier price is self-inconsistent between the tier card ($49) and comparison table ($25). Egress billed $0.01/GB intra-cloud, $0.10/GB inter-cloud.",
  "disposition": "register"
}

{
  "id": "P09-C-022",
  "evidence_class": "observed",
  "source": "https://motherduck.com/pricing/",
  "observed": "2026-08-27",
  "name": "MotherDuck",
  "category": "analytics",
  "claim": "MotherDuck prices internal users, not end users: 'unlimited end users' on all plans with only internal users metered, Business at $250/org/month plus usage (storage $0.04/GB/mo, compute $0.60-$24/hr by instance class). It markets 'Hypertenancy', giving each internal or end user an isolated compute instance, plus up to 16 read-scaling replicas.",
  "tenancy_model": "hypertenancy: isolated compute instance per user; read-scaling replicas for concurrent readers",
  "workload_shapes": [
    "analytics"
  ],
  "limitations": "'Hypertenancy' and per-user isolated instances are vendor terminology read off the pricing page; no independent verification of the isolation boundary's strength. Free Lite tier caps at 3 internal users and 10 GB.",
  "disposition": "register"
}

{
  "id": "P09-C-023",
  "evidence_class": "observed",
  "source": "https://www.confluent.io/confluent-cloud/pricing/",
  "observed": "2026-08-27",
  "name": "Confluent Cloud",
  "category": "events-streaming",
  "claim": "Confluent bills elastic CKUs plus networking and storage: Basic (first eCKU free, then $0.14/hr, $0.05/GB, 5 TB cap), Standard ($0.75/hr, ~$385/mo start), Enterprise ($1.75-2.25/hr, ~$895/mo), Freight ($2.25/hr min 2 eCKUs, ~$2,300/mo). There is no per-partition charge, only partition limits (1,500 Basic to 96,000 Enterprise).",
  "tenancy_model": "cluster/environment separation; topic naming and ACLs carry tenancy, no tenant primitive",
  "workload_shapes": [
    "events"
  ],
  "limitations": "Page gives no multi-tenant sizing guidance for Confluent Cloud; the only multi-tenant mention is Confluent Private Cloud on your own infrastructure. Dedicated cluster pricing is sales-gated. Partition limits, not cost, are the real constraint on topic-per-tenant.",
  "disposition": "register"
}

{
  "id": "P09-C-024",
  "evidence_class": "observed",
  "source": "https://raw.githubusercontent.com/redpanda-data/redpanda/dev/licenses/bsl.md",
  "observed": "2026-08-27",
  "name": "Redpanda",
  "category": "events-streaming",
  "claim": "Redpanda is Kafka-API compatible but its LICENSE body is Business Source License 1.1 with an Additional Use Grant that bars using it for a 'Streaming or Queuing Service' -- explicitly including any commercial offering letting third parties cause topic creation, and naming infrastructure/hosting providers. Change Date is four years from release. TOP10: a host foundation that let tenants create topics could fall inside this carve-out, making it a direct legal constraint on a multi-tenant event plane.",
  "tenancy_model": "topic/ACL-based; no tenant primitive",
  "workload_shapes": [
    "events"
  ],
  "limitations": "GitHub API reports the licence as None/null because the LICENSE lives under licenses/bsl.md rather than the repo root, so automated licence tooling would report nothing at all. Whether Actionist's specific product shape triggers the Additional Use Grant is a legal question, not a technical one; not resolved here.",
  "disposition": "top10"
}

{
  "id": "P09-C-025",
  "evidence_class": "observed",
  "source": "https://api.github.com/repos/nats-io/nats-server",
  "observed": "2026-08-27",
  "name": "NATS / Synadia",
  "category": "events-streaming",
  "claim": "nats-io/nats-server is Apache-2.0 (SPDX confirmed, ~20.6k stars), 'the cloud and edge native messaging system'. Unlike Redpanda's BSL, a permissive licence imposes no carve-out on offering messaging to third parties, making it the licence-safe choice for a host that must let donor systems publish and subscribe.",
  "tenancy_model": "NATS accounts provide a first-class multi-tenancy primitive with subject isolation (inferred from product architecture, not read here)",
  "workload_shapes": [
    "events"
  ],
  "limitations": "Only the licence and description were observed via the API. The accounts-as-tenancy claim is inferred from general NATS architecture knowledge and was NOT verified against docs in this run; Synadia Cloud pricing was not fetched.",
  "disposition": "register"
}

{
  "id": "P09-C-026",
  "evidence_class": "observed",
  "source": "https://raw.githubusercontent.com/elastic/elasticsearch/main/LICENSE.txt",
  "observed": "2026-08-27",
  "name": "Elastic / Elasticsearch",
  "category": "search",
  "claim": "Read the body, not the badge: Elasticsearch is triple-licensed under 'GNU Affero General Public License v3.0 only', 'the Server Side Public License, v 1', and 'the Elastic License 2.0', with code licensed SOLELY under ELv2 found in the x-pack folder. GitHub's API returns no licence field at all for this repo. TOP10: the ELv2-only x-pack carve-out is precisely the hosting-clause trap this project has already been burned by, and it sits inside the most commonly assumed-safe search dependency.",
  "tenancy_model": "index-per-tenant or filtered alias; document-level security is an x-pack (ELv2) feature",
  "workload_shapes": [
    "search",
    "vector",
    "analytics"
  ],
  "limitations": "Document-level security living in x-pack means the tenancy feature is the ELv2-encumbered part, which was inferred from the licence structure rather than verified feature-by-feature. Elastic Cloud Serverless pricing page returned 404 and was not read.",
  "disposition": "top10"
}

{
  "id": "P09-C-027",
  "evidence_class": "observed",
  "source": "https://www.algolia.com/doc/guides/security/api-keys/how-to/user-restricted-access-to-data/",
  "observed": "2026-08-27",
  "name": "Algolia",
  "category": "search",
  "claim": "Algolia documents tenancy WITHOUT per-tenant indices: 'This doesn't mean you need one index per user.' Records carry a filterable access attribute (e.g. visible_by), and the backend mints a secured API key with an embedded filter that 'users can't alter', so a browser-side key is cryptographically constrained to one tenant's rows. TOP10: the strongest commercial precedent for pushing a tenant-scoped credential to an untrusted client, which is exactly what a host must do for donor-app frontends it does not control.",
  "tenancy_model": "row-level via filter embedded in a signed secured API key over a shared index",
  "workload_shapes": [
    "search"
  ],
  "limitations": "The access attribute must be added to unretrievableAttributes or responses leak who else has access. Compromise is remediated only by invalidating the parent search key, revoking every derived key at once. Indices capped at 20-1,000 per app depending on plan.",
  "disposition": "top10"
}

{
  "id": "P09-C-028",
  "evidence_class": "observed",
  "source": "https://www.algolia.com/pricing",
  "observed": "2026-08-27",
  "name": "Algolia (commercial tiers)",
  "category": "search",
  "claim": "Algolia meters search requests and records: Free (10K searches, 50K records), Grow ($0.50 per additional 1K searches, $0.40 per 1K records), Grow Plus ($1.75 per 1K searches), Elevate (annual, custom). A search request counts once per exchange even across multiple indices, and Algolia ignores the 3 highest-record days each month.",
  "tenancy_model": "n/a (pricing)",
  "workload_shapes": [
    "search"
  ],
  "limitations": "Pricing page never mentions secured API keys, so the tenancy mechanism and the commercial terms had to be verified from two separate sources. Pre-sorted replicas inflate the billable record count.",
  "disposition": "register"
}

{
  "id": "P09-C-029",
  "evidence_class": "observed",
  "source": "https://api.github.com/repos/typesense/typesense",
  "observed": "2026-08-27",
  "name": "Typesense",
  "category": "search",
  "claim": "Typesense is GPL-3.0 (SPDX confirmed and corroborated by the LICENSE.txt body reading 'GNU GENERAL PUBLIC LICENSE', ~26.5k stars), self-describing as an 'Open Source alternative to Algolia + Pinecone'. GPL-3.0 is a genuine OSI licence with no hosting carve-out, but its copyleft reach is a different question from ELv2/BSL commercial restrictions.",
  "tenancy_model": "collection-per-tenant or scoped search keys (not verified in this run)",
  "workload_shapes": [
    "search",
    "vector"
  ],
  "limitations": "Only the licence was verified. Typesense Cloud pricing and its scoped-API-key tenancy mechanism were NOT fetched; the tenancy_model field is therefore inferred from category norms.",
  "disposition": "register"
}

{
  "id": "P09-C-030",
  "evidence_class": "observed",
  "source": "https://www.pinecone.io/pricing/",
  "observed": "2026-08-27",
  "name": "Pinecone",
  "category": "vector",
  "claim": "Pinecone's namespace is the tenancy primitive, with documented per-index limits of 100 (Starter), 1,000 (Builder) and 100,000 (Standard and Enterprise), making namespace-per-tenant viable at scale. Pricing is serverless/usage-based: $0.33/GB/mo storage, ~$4-4.50 per million write units and ~$16-18 per million read units on Standard, with $50 (Standard) and $500 (Enterprise) monthly minimums.",
  "tenancy_model": "namespace-per-tenant within a shared index (100k namespaces on paid tiers)",
  "workload_shapes": [
    "vector"
  ],
  "limitations": "The pricing page does not define namespaces in depth; the namespace-per-tenant pattern is inferred from the documented per-plan namespace limits plus general Pinecone practice. Egress $0.10/GB above 100 GB included.",
  "disposition": "register"
}

{
  "id": "P09-C-031",
  "evidence_class": "observed",
  "source": "https://temporal.io/pricing",
  "observed": "2026-08-27",
  "name": "Temporal Cloud",
  "category": "workflow-state",
  "claim": "Temporal Cloud makes durable workflow state a metered product: Actions billed at $50/million falling to $25/million at volume, active storage $0.042/GBh and retained storage $0.00105/GBh, with plans from Essentials $100/mo to Enterprise, paying 'the greater of your monthly plan or 5%-10% of usage'. Namespaces default to On-Demand at 500 APS, autoscaling on 7-day usage. The OSS server is MIT (SPDX confirmed, ~22.6k stars).",
  "tenancy_model": "namespace as the isolation/capacity unit; namespace-to-tenant mapping NOT confirmed on the pricing page",
  "workload_shapes": [
    "workflow"
  ],
  "limitations": "The page discusses namespaces only in a capacity context and never defines namespace-to-tenancy, so namespace-per-tenant remains unconfirmed. Per-action pricing punishes chatty workflows, and retained storage means abandoned tenant workflows keep billing.",
  "disposition": "register"
}

{
  "id": "P09-C-032",
  "evidence_class": "observed",
  "source": "https://raw.githubusercontent.com/inngest/inngest/main/LICENSE.md",
  "observed": "2026-08-27",
  "name": "Inngest",
  "category": "workflow-state",
  "claim": "Inngest ('The leading workflow orchestration platform', ~5.8k stars) carries a LICENSE body of 'Server Side Public License, Version 1.0' with an Apache 2.0 Future License. SSPL is the strongest copyleft-for-service licence in this survey: offering the functionality as a service triggers obligations over the entire service stack.",
  "tenancy_model": "event-key/environment separation; no tenant primitive verified",
  "workload_shapes": [
    "workflow",
    "events"
  ],
  "limitations": "GitHub API reports NOASSERTION, concealing SSPL from automated tooling -- the third such false negative in this survey. Inngest cloud pricing tiers were not fetched. Whether the Apache-2.0 future conversion date has passed for any given release was not checked.",
  "disposition": "register"
}

{
  "id": "P09-C-033",
  "evidence_class": "observed",
  "source": "https://liveblocks.io/pricing",
  "observed": "2026-08-27",
  "name": "Liveblocks",
  "category": "sync-collaborative",
  "claim": "Liveblocks prices the room as the collaborative-state unit: unlimited monthly active users AND unlimited monthly active rooms on every tier, metering instead on simultaneous connections per room (10/10/50/100), realtime collaboration minutes ($0.002/minute beyond 3,000), and realtime data stored per room (10 MB Free/Pro, 50 MB Team). Yjs is included on all tiers alongside Liveblocks Storage. Plans: Free, Pro $25/mo, Team $500/mo (annual).",
  "tenancy_model": "room-per-document/per-entity, unlimited rooms; tenancy is a room-naming and access-token concern",
  "workload_shapes": [
    "sync",
    "document"
  ],
  "limitations": "Facts extracted by text-scraping the rendered pricing page rather than an interactive read, so tier-to-number alignment across the comparison table is approximate. The 10 MB per-room storage ceiling is a hard design constraint for document-heavy donor apps.",
  "disposition": "register"
}

{
  "id": "P09-C-034",
  "evidence_class": "observed",
  "source": "https://api.github.com/repos/jamsocket/y-sweet",
  "observed": "2026-08-27",
  "name": "Y-Sweet (Jamsocket)",
  "category": "sync-collaborative",
  "claim": "y-sweet is MIT-licensed (verified by reading the LICENSE body, which returns 'MIT License'), providing a self-hostable Yjs CRDT server with S3-compatible persistence. It is the licence-safe alternative to Liveblocks for collaborative state, with no Competing Use or hosting carve-out.",
  "tenancy_model": "document-per-entity with S3-backed persistence; tenancy via document key namespacing",
  "workload_shapes": [
    "sync",
    "document",
    "files"
  ],
  "limitations": "Only the licence body was verified. Jamsocket's hosted pricing, scaling limits, and auth model were NOT fetched in this run; the tenancy_model is inferred from Yjs/y-sweet architecture rather than observed documentation.",
  "disposition": "register"
}

{
  "id": "P09-C-035",
  "evidence_class": "inferred",
  "source": "https://www.crunchydata.com/pricing",
  "observed": "2026-08-27",
  "name": "Crunchy Data / Crunchy Bridge",
  "category": "managed-postgres",
  "claim": "Crunchy Bridge is a managed Postgres offering positioned for enterprises wanting standard Postgres without proprietary extensions, which for a host means donor databases can be lifted in and out without a vendor-specific dialect. Marked INFERRED: the pricing page fetch was blocked by a rate limit and no page was read in this run.",
  "tenancy_model": "standard Postgres tenancy (RLS, schema-per-tenant, db-per-tenant) with no vendor-specific primitive",
  "workload_shapes": [
    "transactional"
  ],
  "limitations": "NOT VERIFIED. The WebFetch call for crunchydata.com/pricing failed with a model usage limit before returning content, and the reported Snowflake acquisition was not confirmed. Every claim here is category-level inference and must be re-verified before use in any client deliverable.",
  "disposition": "rejected"
}