Category: Best Practices

Best practices in graph database development represent the collective wisdom gained from real-world production deployments, performance optimization efforts, and lessons learned from building scalable, maintainable systems. This category provides battle-tested patterns, anti-patterns to avoid, and pragmatic guidance for building robust applications with Geode. These practices span the entire development lifecycle from initial graph modeling and schema design through query optimization, transaction management, security hardening, and operational monitoring. They reflect Geode’s ISO/IEC 39075:2024 compliance, 97.4% test coverage achievements, and production deployment experiences across diverse use cases. Following these best practices helps teams avoid common pitfalls, achieve optimal performance, maintain data integrity, and build systems that scale gracefully as data and usage grow. Each recommendation is backed by specific examples and explains the rationale behind the practice. <h3 id="graph-modeling-best-practices" class="position-relative d-flex align-items-center group"> Graph Modeling Best Practices <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="graph-modeling-best-practices" aria-haspopup="dialog" aria-label="Share link: Graph Modeling Best Practices"> Share link </button> </h3><div id="headingShareModal" class="heading-share-modal" role="dialog" aria-modal="true" aria-labelledby="headingShareTitle" hidden> <div class="hsm-dialog" role="document"> <div class="hsm-header"> <h2 id="headingShareTitle" class="h6 mb-0 fw-bold">Share this section</h2> <button type="button" class="hsm-close" aria-label="Close"> </button> </div> <div class="hsm-body"> <label for="headingShareInput" class="form-label small text-muted mb-1 text-uppercase fw-bold" style="font-size: 0.7rem; letter-spacing: 0.5px;">Permalink</label> <div class="input-group mb-4 hsm-url-group"> <input id="headingShareInput" type="text" class="form-control font-monospace" readonly aria-readonly="true" style="font-size: 0.85rem;" /> <button class="btn btn-primary hsm-copy" type="button" aria-label="Copy" title="Copy"> </button> </div> <div class="small fw-bold mb-2 text-muted text-uppercase" style="font-size: 0.7rem; letter-spacing: 0.5px;">Share via</div> <div class="hsm-share-grid"> <a id="share-twitter" class="btn btn-outline-secondary w-100" target="_blank" rel="noopener noreferrer"> Twitter </a> <a id="share-linkedin" class="btn btn-outline-secondary w-100" target="_blank" rel="noopener noreferrer"> LinkedIn </a> <a id="share-facebook" class="btn btn-outline-secondary w-100" target="_blank" rel="noopener noreferrer"> Facebook </a> </div> </div> </div> </div> <style> .heading-share-modal { position: fixed; inset: 0; display: flex; justify-content: center; align-items: center; background: rgba(0, 0, 0, 0.6); z-index: 1050; padding: 1rem; backdrop-filter: blur(4px); -webkit-backdrop-filter: blur(4px); } .heading-share-modal[hidden] { display: none !important; } .hsm-dialog { max-width: 420px; width: 100%; background: var(--bs-body-bg, #fff); color: var(--bs-body-color, #212529); border: 1px solid var(--bs-border-color, rgba(0,0,0,0.1)); border-radius: 1rem; box-shadow: 0 25px 50px -12px rgba(0, 0, 0, 0.25); overflow: hidden; animation: hsm-fade-in 0.2s ease-out; } @keyframes hsm-fade-in { from { opacity: 0; transform: scale(0.95); } to { opacity: 1; transform: scale(1); } } [data-bs-theme="dark"] .hsm-dialog { background: #1e293b; border-color: rgba(255,255,255,0.1); color: #f8f9fa; } .hsm-header { display: flex; justify-content: space-between; align-items: center; padding: 1rem 1.5rem; border-bottom: 1px solid var(--bs-border-color, rgba(0,0,0,0.1)); background: rgba(0,0,0,0.02); } [data-bs-theme="dark"] .hsm-header { background: rgba(255,255,255,0.02); border-color: rgba(255,255,255,0.1); } .hsm-close { background: transparent; border: none; color: inherit; opacity: 0.5; padding: 0.25rem 0.5rem; border-radius: 0.25rem; font-size: 1.2rem; line-height: 1; transition: opacity 0.2s; } .hsm-close:hover { opacity: 1; } .hsm-body { padding: 1.5rem; } .hsm-url-group { display: flex !important; align-items: stretch; } .hsm-url-group .form-control { flex: 1; min-width: 0; margin: 0; background: var(--bs-secondary-bg, #f8f9fa); border-color: var(--bs-border-color, #dee2e6); border-top-right-radius: 0; border-bottom-right-radius: 0; height: 42px; } .hsm-url-group .btn { flex: 0 0 auto; margin: 0; margin-left: -1px; border-top-left-radius: 0; border-bottom-left-radius: 0; height: 42px; display: flex; align-items: center; justify-content: center; padding: 0 1.25rem; z-index: 2; } [data-bs-theme="dark"] .hsm-url-group .form-control { background: #0f172a; border-color: #334155; color: #e2e8f0; } .hsm-share-grid { display: flex; flex-direction: column; gap: 0.5rem; } .hsm-share-grid .btn { display: flex; align-items: center; justify-content: center; font-size: 0.9rem; padding: 0.6rem; border-color: var(--bs-border-color); width: 100%; } [data-bs-theme="dark"] .hsm-share-grid .btn { color: #e2e8f0; border-color: #475569; } [data-bs-theme="dark"] .hsm-share-grid .btn:hover { background: #334155; border-color: #cbd5e1; } </style> <script> (function(){ const modal = document.getElementById('headingShareModal'); if(!modal) return; const input = modal.querySelector('#headingShareInput'); const copyBtn = modal.querySelector('.hsm-copy'); const twitter = modal.querySelector('#share-twitter'); const linkedin = modal.querySelector('#share-linkedin'); const facebook = modal.querySelector('#share-facebook'); const closeBtn = modal.querySelector('.hsm-close'); let lastFocus=null; let trapBound=false; function buildUrl(id){ return window.location.origin + window.location.pathname + '#' + id; } function isOpen(){ return !modal.hasAttribute('hidden'); } function hydrate(id){ const url=buildUrl(id); input.value=url; const enc=encodeURIComponent(url); const text=encodeURIComponent(document.title); if(twitter) twitter.href=`https://twitter.com/intent/tweet?url=${enc}&text=${text}`; if(linkedin) linkedin.href=`https://www.linkedin.com/sharing/share-offsite/?url=${enc}`; if(facebook) facebook.href=`https://www.facebook.com/sharer/sharer.php?u=${enc}`; } function openModal(id){ lastFocus=document.activeElement; hydrate(id); if(!isOpen()){ modal.removeAttribute('hidden'); } requestAnimationFrame(()=>{ input.focus(); }); trapFocus(); } function closeModal(){ if(!isOpen()) return; modal.setAttribute('hidden',''); if(lastFocus && typeof lastFocus.focus==='function') lastFocus.focus(); } function copyCurrent(){ try{ navigator.clipboard.writeText(input.value).then(()=>feedback(true),()=>fallback()); } catch(e){ fallback(); } } function fallback(){ input.select(); try{ document.execCommand('copy'); feedback(true);}catch(e){ feedback(false);} } function feedback(ok){ if(!copyBtn) return; const icon=copyBtn.querySelector('i'); if(!icon) return; const prev=copyBtn.getAttribute('data-prev')||icon.className; if(!copyBtn.getAttribute('data-prev')) copyBtn.setAttribute('data-prev',prev); icon.className= ok ? 'fa-duotone fa-clipboard-check':'fa-duotone fa-circle-exclamation'; setTimeout(()=>{ icon.className=prev; },1800); } function handleShareClick(e){ e.preventDefault(); const btn=e.currentTarget; const id=btn.getAttribute('data-share-target'); if(id) openModal(id); } function bindShareButtons(){ document.querySelectorAll('.h-share').forEach(btn=>{ if(!btn.dataset.hShareBound){ btn.addEventListener('click', handleShareClick); btn.dataset.hShareBound='1'; } }); } bindShareButtons(); if(document.readyState==='loading'){ document.addEventListener('DOMContentLoaded', bindShareButtons); } else { requestAnimationFrame(bindShareButtons); } document.addEventListener('click', function(e){ const shareBtn=e.target.closest && e.target.closest('.h-share'); if(shareBtn && !shareBtn.dataset.hShareBound){ handleShareClick.call(shareBtn, e); } }, true); document.addEventListener('click', e=>{ if(e.target===modal) closeModal(); if(e.target.closest && e.target.closest('.hsm-close')){ e.preventDefault(); closeModal(); } if(copyBtn && (e.target===copyBtn || (e.target.closest && e.target.closest('.hsm-copy')))) { e.preventDefault(); copyCurrent(); } }); document.addEventListener('keydown', e=>{ if(e.key==='Escape' && isOpen()) closeModal(); }); function trapFocus(){ if(trapBound) return; trapBound=true; modal.addEventListener('keydown', f=>{ if(f.key==='Tab' && isOpen()){ const focusable=[...modal.querySelectorAll('a[href],button,input,textarea,select,[tabindex]:not([tabindex="-1"])')].filter(el=>!el.hasAttribute('disabled')); if(!focusable.length) return; const first=focusable[0]; const last=focusable[focusable.length-1]; if(f.shiftKey && document.activeElement===first){ f.preventDefault(); last.focus(); } else if(!f.shiftKey && document.activeElement===last){ f.preventDefault(); first.focus(); } } }); } if(closeBtn) closeBtn.addEventListener('click', e=>{ e.preventDefault(); closeModal(); }); })(); </script> <h4 id="design-for-your-query-patterns" class="position-relative d-flex align-items-center group"> Design for Your Query Patterns <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="design-for-your-query-patterns" aria-haspopup="dialog" aria-label="Share link: Design for Your Query Patterns"> Share link </button> </h4>Model your graph based on how you’ll query it, not how your domain “looks” in theory: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// GOOD: Model relationships that you'll traverse CREATE (:User {id: 1, name: 'Alice'}) -[:FRIEND_OF]->(:User {id: 2, name: 'Bob'}) // Then query efficiently: MATCH (u:User {id: 1})-[:FRIEND_OF]->(friend) RETURN friend.name // AVOID: Storing relationships as properties CREATE (:User {id: 1, name: 'Alice', friends: [2, 3, 4]}) // Requires expensive lookups: MATCH (u:User {id: 1}) UNWIND u.friends AS friend_id MATCH (f:User {id: friend_id}) RETURN f.name </code></pre></div>Why: Graph traversals are O(1) per relationship, while array unwinding and lookups are O(n) and lose the benefits of graph structure. <h4 id="use-specific-relationship-types" class="position-relative d-flex align-items-center group"> Use Specific Relationship Types <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-specific-relationship-types" aria-haspopup="dialog" aria-label="Share link: Use Specific Relationship Types"> Share link </button> </h4>Create specific, semantically meaningful relationship types rather than generic ones with type properties: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// GOOD: Specific relationship types (:Person)-[:WORKS_FOR]->(:Company) (:Person)-[:MANAGES]->(:Person) (:Person)-[:LIVES_IN]->(:City) // Query efficiently with type filtering: MATCH (p:Person)-[:WORKS_FOR]->(c:Company) WHERE c.name = 'TechCorp' RETURN p.name // AVOID: Generic relationships with type properties (:Person)-[:RELATED_TO {type: 'works_for'}]->(:Company) (:Person)-[:RELATED_TO {type: 'manages'}]->(:Person) // Requires filtering every relationship: MATCH (p:Person)-[r:RELATED_TO]->(c:Company) WHERE r.type = 'works_for' AND c.name = 'TechCorp' RETURN p.name </code></pre></div>Why: Relationship type filtering happens at the storage engine level before traversal, while property filtering requires examining every relationship. <h4 id="denormalize-strategically" class="position-relative d-flex align-items-center group"> Denormalize Strategically <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="denormalize-strategically" aria-haspopup="dialog" aria-label="Share link: Denormalize Strategically"> Share link </button> </h4>Balance between normalization and query performance: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// Store frequently accessed aggregates directly CREATE (:User { id: 1, name: 'Alice', friend_count: 342, // Denormalized count avg_post_likes: 45.3, // Denormalized average last_active: datetime() }) // Update denormalized data transactionally BEGIN TRANSACTION MATCH (u:User {id: 1}) CREATE (u)-[:POSTED]->(p:Post {content: 'New post'}) SET u.post_count = u.post_count + 1 COMMIT // Then query without expensive aggregations MATCH (u:User) WHERE u.friend_count > 300 RETURN u.name, u.friend_count ORDER BY u.friend_count DESC </code></pre></div>Why: Aggregations across relationships can be expensive. For frequently queried metrics, denormalize and update transactionally. <h4 id="use-labels-for-categorization" class="position-relative d-flex align-items-center group"> Use Labels for Categorization <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-labels-for-categorization" aria-haspopup="dialog" aria-label="Share link: Use Labels for Categorization"> Share link </button> </h4>Leverage node labels for filtering and indexing: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// GOOD: Use labels for major categories (:User:PremiumUser {name: 'Alice'}) (:User:TrialUser {name: 'Bob'}) CREATE INDEX ON :PremiumUser(created_date) MATCH (u:PremiumUser) WHERE u.created_date >= datetime() - duration('P30D') RETURN COUNT(*) // AVOID: Using properties for categories that affect query patterns (:User {type: 'premium', name: 'Alice'}) (:User {type: 'trial', name: 'Bob'}) // Can't use label-specific indexes MATCH (u:User) WHERE u.type = 'premium' AND u.created_date >= datetime() - duration('P30D') RETURN COUNT(*) </code></pre></div>Why: Labels enable label-specific indexes and more efficient query planning. <h3 id="query-optimization-practices" class="position-relative d-flex align-items-center group"> Query Optimization Practices <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="query-optimization-practices" aria-haspopup="dialog" aria-label="Share link: Query Optimization Practices"> Share link </button> </h3> <h4 id="use-parameters-not-string-concatenation" class="position-relative d-flex align-items-center group"> Use Parameters, Not String Concatenation <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-parameters-not-string-concatenation" aria-haspopup="dialog" aria-label="Share link: Use Parameters, Not String Concatenation"> Share link </button> </h4>Always use parameterized queries for security and performance: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python"># GOOD: Parameterized queries async with client.execute(""" MATCH (u:User {email: $email}) RETURN u """, {'email': user_email}) as result: user = await result.single() # AVOID: String concatenation (SQL injection risk + no plan caching) query = f"MATCH (u:User {{email: '{user_email}'}}) RETURN u" result, _ = await client.query(query) </code></pre></div>Why: Parameterized queries prevent injection attacks, enable query plan caching, and improve performance. <h4 id="limit-early-filter-early" class="position-relative d-flex align-items-center group"> Limit Early, Filter Early <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="limit-early-filter-early" aria-haspopup="dialog" aria-label="Share link: Limit Early, Filter Early"> Share link </button> </h4>Apply filters and limits as early as possible in your query: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// GOOD: Filter and limit early MATCH (u:User) WHERE u.city = 'San Francisco' AND u.last_active >= datetime() - duration('P7D') WITH u LIMIT 100 MATCH (u)-[:FRIEND]->(f:User) RETURN u.name, COLLECT(f.name) AS friends // AVOID: Filtering after expensive operations MATCH (u:User)-[:FRIEND]->(f:User) WITH u, COLLECT(f.name) AS friends WHERE u.city = 'San Francisco' AND u.last_active >= datetime() - duration('P7D') RETURN u.name, friends LIMIT 100 </code></pre></div>Why: Early filtering reduces the working set size before expensive operations like aggregation and traversal. <h4 id="use-explain-and-profile" class="position-relative d-flex align-items-center group"> Use EXPLAIN and PROFILE <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-explain-and-profile" aria-haspopup="dialog" aria-label="Share link: Use EXPLAIN and PROFILE"> Share link </button> </h4>Regularly analyze query execution plans: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// Understand query plan EXPLAIN MATCH (u:User)-[:FRIEND*2..3]-(f:User) WHERE u.city = 'Boston' RETURN DISTINCT f.name // Measure actual performance PROFILE MATCH (u:User)-[:FRIEND*2..3]-(f:User) WHERE u.city = 'Boston' RETURN DISTINCT f.name </code></pre></div>Look for: <ul> <li>Index usage (avoid full scans)</li> <li>Cardinality estimates (ensure statistics are current)</li> <li>Expensive operations (sort, distinct, large aggregations)</li> <li>Traversal depth (limit variable-length paths)</li> </ul> <h4 id="avoid-cartesian-products" class="position-relative d-flex align-items-center group"> Avoid Cartesian Products <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="avoid-cartesian-products" aria-haspopup="dialog" aria-label="Share link: Avoid Cartesian Products"> Share link </button> </h4>Be explicit with relationship patterns: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// GOOD: Explicit relationship path MATCH (u:User)-[:FRIEND]->(friend:User)-[:LIKES]->(p:Post) WHERE u.name = 'Alice' RETURN p.title // AVOID: Separate MATCH clauses without connections MATCH (u:User) WHERE u.name = 'Alice' MATCH (friend:User) MATCH (p:Post) WHERE (friend)-[:LIKES]->(p) RETURN p.title // Creates expensive Cartesian product </code></pre></div>Why: Unconnected patterns create Cartesian products that examine every combination. <h3 id="transaction-management" class="position-relative d-flex align-items-center group"> Transaction Management <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="transaction-management" aria-haspopup="dialog" aria-label="Share link: Transaction Management"> Share link </button> </h3> <h4 id="keep-transactions-short" class="position-relative d-flex align-items-center group"> Keep Transactions Short <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="keep-transactions-short" aria-haspopup="dialog" aria-label="Share link: Keep Transactions Short"> Share link </button> </h4>Minimize transaction duration to reduce lock contention: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python"># GOOD: Short, focused transactions async def update_user(client, user_id, new_data): async with client.connection() as tx: await tx.begin() await tx.execute(""" MATCH (u:User {id: $user_id}) SET u.name = $name, u.email = $email """, {'user_id': user_id, **new_data}) await tx.commit() # AVOID: Long-running transactions async def bad_batch_update(client, users): async with client.connection() as tx: await tx.begin() for user in users: # Holds locks for entire loop await tx.execute(""" MATCH (u:User {id: $user_id}) SET u.name = $name """, user) await asyncio.sleep(0.1) # Never sleep in transactions! await tx.commit() </code></pre></div>Why: Long transactions hold locks longer, increasing contention and reducing throughput. <h4 id="use-savepoints-for-complex-operations" class="position-relative d-flex align-items-center group"> Use Savepoints for Complex Operations <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-savepoints-for-complex-operations" aria-haspopup="dialog" aria-label="Share link: Use Savepoints for Complex Operations"> Share link </button> </h4>Implement partial rollback with savepoints: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">async def complex_operation(client): async with client.connection() as tx: await tx.begin() # Initial work await tx.execute("CREATE (:User {name: 'Alice'})") # Create savepoint before risky operation await tx.savepoint('before_bulk_insert') try: # Risky bulk operation await tx.execute(""" UNWIND $data AS row CREATE (:Item {data: row}) """, {'data': large_dataset}) except Exception as e: # Rollback to savepoint, keep initial work await tx.rollback_to_savepoint('before_bulk_insert') logger.warning(f"Bulk insert failed: {e}") await tx.commit() </code></pre></div>Why: Savepoints allow fine-grained error recovery without losing all work. <h4 id="handle-deadlocks-gracefully" class="position-relative d-flex align-items-center group"> Handle Deadlocks Gracefully <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="handle-deadlocks-gracefully" aria-haspopup="dialog" aria-label="Share link: Handle Deadlocks Gracefully"> Share link </button> </h4>Implement retry logic for transient failures: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">import asyncio from geode_client import DeadlockError async def transactional_update_with_retry(client, max_retries=3): for attempt in range(max_retries): try: async with client.connection() as tx: await tx.begin() result, _ = await tx.query(""" MATCH (u:User {id: $user_id}) SET u.last_updated = datetime() RETURN u """, {'user_id': 123}) await tx.commit() return result except DeadlockError: if attempt == max_retries - 1: raise await asyncio.sleep(0.1 * (2 ** attempt)) # Exponential backoff </code></pre></div>Why: Deadlocks are inevitable in concurrent systems; graceful retry prevents cascading failures. <h3 id="indexing-strategy" class="position-relative d-flex align-items-center group"> Indexing Strategy <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="indexing-strategy" aria-haspopup="dialog" aria-label="Share link: Indexing Strategy"> Share link </button> </h3> <h4 id="create-indexes-for-frequent-lookups" class="position-relative d-flex align-items-center group"> Create Indexes for Frequent Lookups <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="create-indexes-for-frequent-lookups" aria-haspopup="dialog" aria-label="Share link: Create Indexes for Frequent Lookups"> Share link </button> </h4>Index properties used in WHERE clauses and joins: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// Create single-property indexes CREATE INDEX user_email_idx ON :User(email) CREATE INDEX post_created_idx ON :Post(created_date) // Create composite indexes for multi-property queries CREATE INDEX user_location_idx ON :User(city, state) // Use indexes in queries MATCH (u:User) WHERE u.email = $email // Uses user_email_idx RETURN u MATCH (p:Post) WHERE p.created_date >= $start_date // Uses post_created_idx AND p.created_date < $end_date RETURN p </code></pre></div>Why: Indexes convert O(n) scans to O(log n) lookups. <h4 id="monitor-index-usage" class="position-relative d-flex align-items-center group"> Monitor Index Usage <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="monitor-index-usage" aria-haspopup="dialog" aria-label="Share link: Monitor Index Usage"> Share link </button> </h4>Regularly check index effectiveness: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"># View index statistics geode index stats # Identify unused indexes geode index analyze --show-unused # Drop unused indexes geode index drop user_unused_idx </code></pre></div>Why: Unnecessary indexes slow down writes and consume memory. <h4 id="use-covering-indexes-when-possible" class="position-relative d-flex align-items-center group"> Use Covering Indexes When Possible <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-covering-indexes-when-possible" aria-haspopup="dialog" aria-label="Share link: Use Covering Indexes When Possible"> Share link </button> </h4>Include all queried properties in the index: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// Create covering index CREATE INDEX user_profile_idx ON :User(email, name, city) // Query can be satisfied entirely from index MATCH (u:User) WHERE u.email = $email RETURN u.name, u.city // No need to fetch node data </code></pre></div>Why: Covering indexes eliminate node data access, improving query performance. <h3 id="security-best-practices" class="position-relative d-flex align-items-center group"> Security Best Practices <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="security-best-practices" aria-haspopup="dialog" aria-label="Share link: Security Best Practices"> Share link </button> </h3> <h4 id="use-row-level-security-rls" class="position-relative d-flex align-items-center group"> Use Row-Level Security (RLS) <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="use-row-level-security-rls" aria-haspopup="dialog" aria-label="Share link: Use Row-Level Security (RLS)"> Share link </button> </h4>Implement data-level access control: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// Create RLS policy CREATE POLICY user_data_isolation ON :UserData USING (node.owner_id = current_user_id()) WITH CHECK (node.owner_id = current_user_id()) // Queries automatically enforce policy MATCH (d:UserData) RETURN d.content // Users only see their own data </code></pre></div>Why: RLS provides mandatory access control that can’t be bypassed by application bugs. <h4 id="never-store-plaintext-secrets" class="position-relative d-flex align-items-center group"> Never Store Plaintext Secrets <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="never-store-plaintext-secrets" aria-haspopup="dialog" aria-label="Share link: Never Store Plaintext Secrets"> Share link </button> </h4>Use Field-Level Encryption (FLE) for sensitive data: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">from geode_client import EncryptedField await client.execute(""" CREATE (:User { name: $name, ssn: $ssn, credit_card: $cc }) """, { 'name': 'Alice', 'ssn': EncryptedField('123-45-6789', key_id='pii'), 'cc': EncryptedField('4111-1111-1111-1111', key_id='payment') }) </code></pre></div>Why: FLE ensures data is encrypted end-to-end, even if database is compromised. <h4 id="implement-least-privilege" class="position-relative d-flex align-items-center group"> Implement Least Privilege <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="implement-least-privilege" aria-haspopup="dialog" aria-label="Share link: Implement Least Privilege"> Share link </button> </h4>Grant minimal necessary permissions: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-gql" data-lang="gql">// Create role with limited permissions CREATE ROLE analyst_role // Grant only required operations GRANT MATCH ON DATABASE mydb TO analyst_role GRANT READ ON GRAPH analytics_graph TO analyst_role // Don't grant unnecessary permissions // DENY WRITE ON DATABASE mydb TO analyst_role // DENY ADMIN ON DATABASE mydb TO analyst_role </code></pre></div>Why: Principle of least privilege minimizes damage from compromised accounts. <h3 id="performance-and-scalability" class="position-relative d-flex align-items-center group"> Performance and Scalability <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="performance-and-scalability" aria-haspopup="dialog" aria-label="Share link: Performance and Scalability"> Share link </button> </h3> <h4 id="connection-pooling" class="position-relative d-flex align-items-center group"> Connection Pooling <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="connection-pooling" aria-haspopup="dialog" aria-label="Share link: Connection Pooling"> Share link </button> </h4>Reuse connections efficiently: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">from geode_client import ConnectionPool # Configure pool pool = ConnectionPool( host='localhost', port=3141, min_size=5, max_size=20, max_idle_time=300 # 5 minutes ) async def query_with_pool(): async with pool.acquire() as client: result, _ = await client.query("MATCH (n:User) RETURN COUNT(n)") return result.single() </code></pre></div>Why: Connection establishment is expensive; pooling amortizes overhead. <h4 id="batch-operations" class="position-relative d-flex align-items-center group"> Batch Operations <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="batch-operations" aria-haspopup="dialog" aria-label="Share link: Batch Operations"> Share link </button> </h4>Group operations for efficiency: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python"># GOOD: Batch insert async def batch_insert(client, users): await client.execute(""" UNWIND $users AS user CREATE (:User { name: user.name, email: user.email, created_at: datetime() }) """, {'users': users}) # AVOID: Individual inserts async def individual_inserts(client, users): for user in users: await client.execute(""" CREATE (:User {name: $name, email: $email}) """, user) # Separate network round-trip per insert </code></pre></div>Why: Batching reduces network round-trips and transaction overhead. <h4 id="monitor-and-alert" class="position-relative d-flex align-items-center group"> Monitor and Alert <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="monitor-and-alert" aria-haspopup="dialog" aria-label="Share link: Monitor and Alert"> Share link </button> </h4>Implement comprehensive monitoring: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-yaml" data-lang="yaml"># prometheus.yml scrape_configs: - job_name: 'geode' static_configs: - targets: ['localhost:9090'] metrics_path: '/metrics' # Key metrics to monitor: # - geode_query_duration_seconds (query latency) # - geode_transaction_commits_total (throughput) # - geode_mvcc_snapshot_age_seconds (long transactions) # - geode_wal_sync_duration_seconds (disk performance) # - geode_connection_pool_active (connection usage) </code></pre></div>Why: Proactive monitoring prevents outages and identifies optimization opportunities. <h3 id="development-workflow" class="position-relative d-flex align-items-center group"> Development Workflow <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="development-workflow" aria-haspopup="dialog" aria-label="Share link: Development Workflow"> Share link </button> </h3> <h4 id="test-with-representative-data" class="position-relative d-flex align-items-center group"> Test with Representative Data <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="test-with-representative-data" aria-haspopup="dialog" aria-label="Share link: Test with Representative Data"> Share link </button> </h4>Use production-scale test data: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python"># Generate realistic test data async def setup_test_data(client): # Create diverse graph structure await client.execute(""" UNWIND range(1, 10000) AS user_id CREATE (u:User { id: user_id, name: 'User' + user_id, created: datetime() - duration('P' + (user_id % 365) + 'D') }) """) # Create relationships with realistic distribution await client.execute(""" MATCH (u1:User), (u2:User) WHERE rand() < 0.01 // 1% connection probability AND id(u1) < id(u2) CREATE (u1)-[:FRIEND]->(u2) """) </code></pre></div>Why: Performance characteristics change dramatically with data scale. <h4 id="version-control-your-queries" class="position-relative d-flex align-items-center group"> Version Control Your Queries <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="version-control-your-queries" aria-haspopup="dialog" aria-label="Share link: Version Control Your Queries"> Share link </button> </h4>Treat queries as code: <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-python" data-lang="python"># queries/users.py GET_USER_FRIENDS = """ MATCH (u:User {id: $user_id})-[:FRIEND]->(f:User) RETURN f.name, f.email ORDER BY f.name """ GET_POPULAR_POSTS = """ MATCH (p:Post)<-[:LIKES]-(u:User) WITH p, COUNT(u) AS likes WHERE likes > $min_likes RETURN p.title, likes ORDER BY likes DESC LIMIT $limit """ # Use in application from queries.users import GET_USER_FRIENDS result, _ = await client.query(GET_USER_FRIENDS, {'user_id': 123}) </code></pre></div>Why: Query versioning enables review, testing, and change tracking. <h3 id="further-reading" class="position-relative d-flex align-items-center group"> Further Reading <button type="button" class="h-share btn btn-link p-0 text-decoration-none link-secondary opacity-50 hover-opacity-100 transition-all ms-1" data-share-target="further-reading" aria-haspopup="dialog" aria-label="Share link: Further Reading"> Share link </button> </h3><ul> <li><a href="/tags/data-model/" >Graph Modeling Guide</a> - Schema design patterns</li> <li><a href="/categories/query-optimization/" >Query Optimization</a> - Performance tuning</li> <li><a href="/categories/security/" >Security Practices</a> - Hardening and compliance</li> <li><a href="/tags/transactions/" >Transaction Management</a> - ACID and concurrency</li> <li><a href="/tags/monitoring/" >Monitoring and Operations</a> - Production best practices</li> <li><a href="/tags/performance/" >Performance Tuning</a> - Optimization techniques</li> <li><a href="/tags/indexing/" >Index Management</a> - Index strategies</li> </ul>

Popular

Related Articles

Guides