Multiple Databases: Isolation, Administration, Security, Resource Considerations, and Tenant Boundaries

AtlasMart has grown from one graph into three accountable domains: Catalog owns product descriptions and current prices; Customer owns profile/tier data; Orders owns commercial facts such as order status and the unit price charged at purchase time. A proposal says “put each domain in a database and we get tenant isolation for free.” That statement mixes at least five different boundaries: data files, transactions, security, resources, and failure/recovery. This lesson separates them before any federation feature is introduced.

Learning outcomes

Reproducible Chapter 19 lab baseline

1. The first edition fact changes the lab design

2. Database isolation has several dimensions

3. Start the free multi-instance laboratory

The ports deliberately avoid the course baseline container on 7474/7687. Each Chapter 19 container runs one Community standard database named neo4j. The Docker network is for optional container-to-container exercises; the Python lab uses loopback Bolt ports from the host.

# PowerShell / Bash-compatible Docker commands (line continuations omitted intentionally)
docker network create atlasmart-ch19-net

docker run -d --name atlasmart-ch19-catalog --network atlasmart-ch19-net \
  -p 7574:7474 -p 7767:7687 \
  -e NEO4J_AUTH=neo4j/atlasmart-course-2026 \
  -v atlasmart-ch19-catalog-data:/data neo4j:2026.07.1

docker run -d --name atlasmart-ch19-orders --network atlasmart-ch19-net \
  -p 7575:7474 -p 7768:7687 \
  -e NEO4J_AUTH=neo4j/atlasmart-course-2026 \
  -v atlasmart-ch19-orders-data:/data neo4j:2026.07.1

docker run -d --name atlasmart-ch19-customers --network atlasmart-ch19-net \
  -p 7576:7474 -p 7769:7687 \
  -e NEO4J_AUTH=neo4j/atlasmart-course-2026 \
  -v atlasmart-ch19-customers-data:/data neo4j:2026.07.1

# Verify process/port state; availability timing varies by machine.
docker ps --filter name=atlasmart-ch19-

4. Seed facts where their owner lives

Catalog owns Product; Customers owns Customer; Orders owns Order plus identity-only CustomerRef and ProductRef proxies. The order line stores unitPrice because that is an immutable commercial fact at purchase time; Catalog’s currentPrice can later change without rewriting history.

CYPHER 25
CREATE CONSTRAINT ch19_product_id IF NOT EXISTS
FOR (p:Product) REQUIRE p.productId IS UNIQUE;
UNWIND [
  {id:'P-1901', name:'Trail Camera', category:'Cameras', price:129.90},
  {id:'P-1902', name:'Weather Case', category:'Accessories', price:39.50},
  {id:'P-1903', name:'Sensor Hub', category:'Store IoT', price:249.00}
] AS row
MERGE (p:Product {productId:row.id})
SET p.name=row.name, p.category=row.category, p.price=row.price, p.labTag='ch19';

CYPHER 25
CREATE CONSTRAINT ch19_customer_id IF NOT EXISTS
FOR (c:Customer) REQUIRE c.customerId IS UNIQUE;
UNWIND [
  {id:'C-1901', name:'Ada Lovelace', tier:'gold'},
  {id:'C-1902', name:'Grace Hopper', tier:'silver'},
  {id:'C-1903', name:'Katherine Johnson', tier:'gold'}
] AS row
MERGE (c:Customer {customerId:row.id})
SET c.name=row.name, c.tier=row.tier, c.labTag='ch19';

CYPHER 25
CREATE CONSTRAINT ch19_order_id IF NOT EXISTS
FOR (o:Order) REQUIRE o.orderId IS UNIQUE;
CREATE CONSTRAINT ch19_customer_ref_id IF NOT EXISTS
FOR (c:CustomerRef) REQUIRE c.customerId IS UNIQUE;
CREATE CONSTRAINT ch19_product_ref_id IF NOT EXISTS
FOR (p:ProductRef) REQUIRE p.productId IS UNIQUE;

UNWIND [
  {orderId:'O-1901', customerId:'C-1901', status:'PAID'},
  {orderId:'O-1902', customerId:'C-1902', status:'SHIPPED'},
  {orderId:'O-1903', customerId:'C-1903', status:'PAID'}
] AS row
MERGE (o:Order {orderId:row.orderId})
SET o.status=row.status, o.labTag='ch19'
MERGE (c:CustomerRef {customerId:row.customerId})
SET c.labTag='ch19'
MERGE (o)-[:PLACED_BY]->(c);

UNWIND [
  {orderId:'O-1901', productId:'P-1901', quantity:1, unitPrice:129.90},
  {orderId:'O-1901', productId:'P-1902', quantity:2, unitPrice:39.50},
  {orderId:'O-1902', productId:'P-1903', quantity:1, unitPrice:249.00},
  {orderId:'O-1903', productId:'P-1901', quantity:1, unitPrice:129.90}
] AS row
MATCH (o:Order {orderId:row.orderId})
MERGE (p:ProductRef {productId:row.productId})
SET p.labTag='ch19'
MERGE (o)-[r:CONTAINS]->(p)
SET r.quantity=row.quantity, r.unitPrice=row.unitPrice;

CYPHER 25
// Run on catalog
MATCH (p:Product {labTag:'ch19'}) RETURN count(p) AS products;
// Expected: 3

// Run on customers
MATCH (c:Customer {labTag:'ch19'}) RETURN count(c) AS customers;
// Expected: 3

// Run on orders
MATCH (o:Order {labTag:'ch19'}) RETURN count(o) AS orders;
MATCH (:Order {labTag:'ch19'})-[r:CONTAINS]->(:ProductRef) RETURN count(r) AS lines;
// Expected: orders=3, lines=4

5. A proxy is an identity contract, not a cross-graph edge

6. Simulate federation explicitly in application code

The free path queries Orders first, extracts stable keys, then fetches Customer and Product data in bounded batches. The program prints measured per-domain timings from the learner’s machine; no timing threshold is prescribed. This is intentionally not called a composite database.

from neo4j import GraphDatabase
from time import perf_counter

AUTH = ("neo4j", "atlasmart-course-2026")
drivers = {
    "orders": GraphDatabase.driver("bolt://127.0.0.1:7768", auth=AUTH),
    "customers": GraphDatabase.driver("bolt://127.0.0.1:7769", auth=AUTH),
    "catalog": GraphDatabase.driver("bolt://127.0.0.1:7767", auth=AUTH),
}

def run(domain, query, **params):
    t0 = perf_counter()
    with drivers[domain].session(database="neo4j") as s:
        rows = [r.data() for r in s.run(query, **params)]
    return rows, perf_counter() - t0

order_rows, t_orders = run("orders", """
MATCH (o:Order {orderId:$orderId})-[:PLACED_BY]->(cr:CustomerRef)
MATCH (o)-[li:CONTAINS]->(pr:ProductRef)
RETURN o.orderId AS orderId, o.status AS status,
       cr.customerId AS customerId, pr.productId AS productId,
       li.quantity AS quantity, li.unitPrice AS unitPrice
ORDER BY productId
""", orderId="O-1901")

customer_id = order_rows[0]["customerId"]
product_ids = [r["productId"] for r in order_rows]
customer_rows, t_customers = run("customers", """
MATCH (c:Customer {customerId:$id})
RETURN c.customerId AS customerId, c.name AS customerName, c.tier AS tier
""", id=customer_id)
product_rows, t_catalog = run("catalog", """
MATCH (p:Product) WHERE p.productId IN $ids
RETURN p.productId AS productId, p.name AS productName, p.price AS currentPrice
""", ids=product_ids)

products = {p["productId"]: p for p in product_rows}
result = {
    "orderId": order_rows[0]["orderId"],
    "status": order_rows[0]["status"],
    "customer": customer_rows[0],
    "lines": [{**r, **products[r["productId"]]} for r in order_rows],
}
print(result)
print({"orders_s": t_orders, "customers_s": t_customers, "catalog_s": t_catalog})
for d in drivers.values(): d.close()

7. Tenant boundary judgment

8. Cleanup is part of the boundary

# Remove disposable Chapter 19 Community instances and their data volumes.
docker rm -f atlasmart-ch19-catalog atlasmart-ch19-orders atlasmart-ch19-customers
docker volume rm atlasmart-ch19-catalog-data atlasmart-ch19-orders-data atlasmart-ch19-customers-data
docker network rm atlasmart-ch19-net

Production judgment

Summary and next step

You now have honest domain boundaries and a free reproducible multi-instance model. Lesson 2 adds the Enterprise composite layer and shows exactly what it contributes: logical constituent naming and one query execution context—not a new place where AtlasMart data is stored.

Authoritative references

• Current Neo4j versions — Current self-managed release 2026.07.1 and 5.26.30 LTS snapshot.
• Database administration — Current database/transaction-domain model and the one-standard-database Community versus multi-database Enterprise boundary.
• Create standard databases — Enterprise-only self-managed CREATE DATABASE semantics and system-database administration.
• Show databases — SHOW DATABASES fields including type, role, writer, status, aliases and constituents.
• Composite database concepts — Enterprise-only, unavailable-on-Aura composite semantics, local/remote constituents, compatibility, transactions and proxy-node federation.
• Create composite databases — CREATE COMPOSITE DATABASE and current default Cypher language behavior.
• Query composite databases — USE/CALL graph selection, graph functions, update restrictions, root-scope limits and runtime behavior.
• Composite aliases — Local and remote constituent aliases, SHOW ALIASES evidence, namespace rules and alias limitations.
• Standard aliases — Local/remote alias behavior, credentials, access visibility and current OIDC-forwarding option for remote aliases.
• Composite RBAC — Access must be granted to the composite and constituents; remote constituents enforce remote-user RBAC.
• Composite tutorial — Official federation/sharding example and proxy-node model.
• Database alias command syntax — Current SHOW/CREATE/ALTER alias command forms.
• Cypher USE clause — Current graph-selection clause semantics for composite/federated queries.
• Python driver manual — Official driver lifecycle, sessions, parameters, database selection and application-side orchestration.
• Backup and restore — Operational reminder that constituent data stores—not a composite alias layer—are the recovery units.