Skip to content
NamiDB NamiDB

Your first query

Prerequisites

You only need the Python package — see Install.

Terminal window
pip install namidb

Open a namespace, write, read

Open a Python REPL (python -i, a Jupyter cell, or any .py script):

import namidb


# Open an in-memory namespace. No bucket, no credentials, no disk.
# It lives for as long as this Python process is alive.
client = namidb.Client("memory://demo")


# Write some data.
client.cypher("CREATE (a:Person {name: 'Alice', age: 30})")
client.cypher("CREATE (b:Person {name: 'Bob',   age: 25})")
client.cypher(
    "MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'}) "
    "CREATE (a)-[:KNOWS {since: 2020}]->(b)"
)


# Read it back, with a parameter.
result = client.cypher(
    "MATCH (p:Person) WHERE p.age >= $min RETURN p.name AS name, p.age AS age",
    params={"min": 18},
)


print(result.rows())

That’s it. You have a working graph database, query language, parser, optimizer, executor and storage layer running inside a single Python process — and you wrote three Cypher statements against it.

What just happened

  • memory://demo — opened an ephemeral graph namespace called demo. Nothing was written to disk or to a bucket. Closing the Python process loses everything.
  • CREATE — wrote two Person nodes and one KNOWS relationship. The same engine that powers the Cloud cluster ran these writes through the parser, planner, executor, WAL, and memtable inside your process.
  • MATCH … WHERE … RETURN — read it back. The parameter $min was bound at execution time, the predicate p.age >= 18 was pushed down, and the projection returned only the name and age columns.

Make it durable

When you want the graph to outlive the Python process, only the URI changes — the Python code stays identical:

Where it livesURI
Local diskfile:///var/lib/namidb?ns=demo
MinIO (S3-compatible, local)s3://my-bucket?ns=demo&endpoint=http://localhost:9000&allow_http=true
AWS S3s3://my-bucket?ns=demo&region=us-east-1
Cloudflare R2s3://my-bucket?ns=demo&endpoint=https://<id>.r2.cloudflarestorage.com&region=auto
Google Cloud Storagegs://my-bucket?ns=demo
Azure Blobaz://my-account/my-container?ns=demo

Credentials come from the standard cloud env vars (AWS_ACCESS_KEY_ID, GOOGLE_APPLICATION_CREDENTIALS, etc.). See Storage backends for the per-backend reference.

What’s next