Multi-tenant graph applications

Row-level tenancy works right up until the day it doesn't. When a customer asks how their data is separated from everyone else's, "there's a column" is a harder answer than "they have their own database."

Isolation you can describe in one sentence

Each instance is its own database with its own credentials, its own storage and its own resource limits. A query in one tenant cannot see another tenant's data because there is no shared graph for it to reach into, and a runaway workload cannot exhaust a neighbour's memory.

Sizing per tenant, not per worst case

Your largest customer does not have to set the size of everyone's database. Instances run anywhere from 256 MB to 512 GB of memory, each sized independently, and move up or down the ladder without changing their connection URI.

Billing that follows actual usage

Instances bill by the second, and a paused instance costs only its storage. A tenant that is quiet for a month is close to free, which makes per-tenant provisioning viable well before a tenant is large enough to justify dedicated infrastructure.

Provisioning is an API call

Create instances from the control-plane API, from Terraform with the CognoDB provider, or from the console. Onboarding a tenant becomes part of your signup flow rather than an operations ticket.

Each tenant connects to their own instance — same code, different URI.hcl
# Provisioned per tenant at signup, one instance each
resource "cognodb_instance" "tenant" {
  for_each = var.tenants

  name   = "tenant-${each.key}"
  tier   = "pro"
  size   = each.value.size
  region = each.value.region
}

Other use cases

Graph memory for AI agents

Give an agent a graph it can traverse instead of a transcript it has to re-read. One instance per agent, per session, or per tenant.

MATCH (a:Agent)-[:REMEMBERS]->(f:Fact)Read more

Knowledge graphs

Model people, documents, systems and the relationships between them, then answer questions that span all of them at once.

MATCH (d:Document)-[:MENTIONS]->(e:Entity)Read more

Multi-tenant graph applications

Give every tenant a real database instead of a tenant_id column. Isolation you can point at, and cost that scales with what each one uses.

CREATE (t:Tenant {id: $tenant})Read more

Dependency & impact analysis

Model what depends on what — services, data, teams — and answer "if this breaks or changes, what's affected?" as a traversal instead of a spreadsheet.

MATCH (s:Service)<-[:DEPENDS_ON*1..]-(affected)Read more

Real-time recommendations

Compute "people like you also chose" live from the behaviour graph at request time — so a purchase a second ago changes the next suggestion.

MATCH (u)-[:BOUGHT]->(p)<-[:BOUGHT]-(peer)Read more

Robotics, hardware & the edge

Model the world a fleet shares — robots, devices, assets, tasks and their dependencies — as one graph the whole fleet can query in real time.

MATCH (r:Robot)-[:CAN_REACH]->(z:Zone)<-[:LOCATED_IN]-(a:Asset)Read more

Start now

~98.7%

token efficiency at 2,000 entities — see the footnotes above

Put your first graph up in a minute.

A free instance takes about a minute and no card. Write two MERGE statements, read them back, and you have a living graph — with provenance on every fact.

Start free View the quickstart

First-graph path

Live

  1. Create a free instance

    No card. Ready in about a minute.

  2. Connect your driver

    bolt+ssc:// URI into the driver you already use.

  3. Write two MERGEs

    That's the entire shape of agent memory.

  4. Point an agent at it

    One MCP config block. No integration code.