In the rapidly evolving landscape of AI applications, we’re witnessing an explosion of interest in GraphRAG systems—and for good reason. By combining the relationship-aware power of graph databases with the semantic capabilities of vector embeddings, GraphRAG promises to deliver context-rich responses that traditional RAG systems simply can’t match. But here’s the thing: when you try to scale these systems from proof-of-concept to production, you hit a wall. Hard. Processing times balloon from hours to days, query latencies spike unpredictably, and what looked elegant in development becomes a resource-hungry monster in production. You’ve probably experienced this frustration yourself—watching your carefully crafted GraphRAG system grind to a halt as it tries to process your organization’s knowledge base.
This performance challenge isn’t just an inconvenience; it’s a fundamental barrier to GraphRAG adoption. When your baseline implementation takes 25 times longer to process 10 times more data, you’re not dealing with linear scaling—you’re facing an exponential problem that threatens the viability of your entire AI initiative. The promise of GraphRAG remains tantalizingly out of reach for many teams who can’t afford to wait days for their knowledge graphs to update.
But what if I told you that these performance issues aren’t inherent to GraphRAG itself? Through extensive benchmarking and real-world implementations, we’ve discovered that the difference between a sluggish GraphRAG system and a high-performance one comes down to understanding where the bottlenecks hide and knowing exactly which optimizations to apply. The teams that crack this code are seeing 10-15x performance improvements, transforming GraphRAG from an interesting research project into a production-ready powerhouse.
In this article, we’ll dive into:
To grasp why GraphRAG systems face unique performance challenges, let’s first understand what makes them tick. Unlike traditional RAG systems that primarily deal with vector similarity searches, GraphRAG orchestrates a complex dance between multiple components, each with its own performance characteristics.
Figure 1: GraphRAG System Architecture – This diagram illustrates the complete flow of a GraphRAG system, from document ingestion through the dual storage mechanism to query processing. Notice how documents are processed through both vector embedding generation and entity extraction pipelines, feeding into separate but connected databases. The retrieval engine can leverage both semantic similarity and graph traversal to assemble comprehensive context for the LLM.
Think of it this way: traditional RAG is like having a really good search engine, while GraphRAG is like having that search engine plus a team of researchers who understand how everything connects. This added sophistication comes at a cost—more moving parts mean more potential bottlenecks.
“When we first deployed GraphRAG for our technical documentation,” recalls Sarah Chen, ML Infrastructure Lead at a Fortune 500 tech company, “we were shocked to find that processing our 10,000-document repository would take nearly two weeks. That’s when we realized that naive implementations simply don’t scale.”
Through our benchmarking efforts across dozens of production deployments, we’ve identified five critical bottlenecks that consistently plague GraphRAG systems:
Document Processing Overhead: The chunking and entity extraction phases often become serial bottlenecks, with each document waiting its turn through the pipeline.
Vector Database Write Amplification: Poor batching strategies can turn thousands of embeddings into millions of individual write operations.
Graph Database Lock Contention: Creating relationships between entities often leads to deadlocks and transaction conflicts, especially in highly connected graphs.
Query-Time Graph Traversal: Unoptimized graph queries can explore exponentially growing paths, leading to timeouts and memory exhaustion.
LLM Context Assembly: Inefficient merging of vector and graph results creates bloated contexts that slow down response generation.
You can’t optimize what you can’t measure. That’s why we developed a benchmarking framework specifically designed for GraphRAG systems. Unlike traditional database benchmarks that focus on isolated operations, our approach captures the interplay between components.
class GraphRAGBenchmark:
"""
Comprehensive benchmarking framework for GraphRAG systems.
Captures both component-level and end-to-end metrics.
"""
def __init__(self, vector_db, graph_db, doc_processor, query_engine):
self.vector_db = vector_db
self.graph_db = graph_db
self.doc_processor = doc_processor
self.query_engine = query_engine
self.metrics = MetricsCollector()
def benchmark_ingestion(self, documents, optimization_config=None):
"""
Benchmark the complete document ingestion pipeline.
Args:
documents: List of documents to process
optimization_config: Configuration for optimizations to test
Returns:
Detailed performance metrics
"""
optimization_config = optimization_config or {}
# Start comprehensive monitoring
with self.metrics.capture() as capture:
# Phase 1: Document Processing
with capture.phase("document_processing"):
chunks = []
for doc in documents:
doc_chunks = self.doc_processor.process(
doc,
chunking_strategy=optimization_config.get('chunking', 'fixed')
)
chunks.extend(doc_chunks)
# Capture intermediate metrics
capture.record("chunks_per_doc", len(doc_chunks))
# Phase 2: Entity Extraction
with capture.phase("entity_extraction"):
entities = []
relationships = []
extraction_batch_size = optimization_config.get('extraction_batch', 1)
for i in range(0, len(chunks), extraction_batch_size):
batch = chunks[i:i + extraction_batch_size]
batch_entities, batch_rels = self.doc_processor.extract_entities(batch)
entities.extend(batch_entities)
relationships.extend(batch_rels)
capture.record("total_entities", len(entities))
capture.record("total_relationships", len(relationships))
# Phase 3: Vector Embedding and Storage
with capture.phase("vector_storage"):
embeddings = self._generate_embeddings(chunks)
vector_batch_size = optimization_config.get('vector_batch', 100)
for i in range(0, len(embeddings), vector_batch_size):
batch = embeddings[i:i + vector_batch_size]
self.vector_db.insert_batch(batch)
# Phase 4: Graph Construction
with capture.phase("graph_construction"):
# Entity creation
entity_batch_size = optimization_config.get('entity_batch', 1000)
for i in range(0, len(entities), entity_batch_size):
batch = entities[i:i + entity_batch_size]
self.graph_db.create_entities(batch)
# Relationship creation with optional grouping
if optimization_config.get('relationship_grouping', False):
rel_groups = self._group_relationships(relationships)
for group in rel_groups:
self.graph_db.create_relationships(group)
else:
rel_batch_size = optimization_config.get('rel_batch', 500)
for i in range(0, len(relationships), rel_batch_size):
batch = relationships[i:i + rel_batch_size]
self.graph_db.create_relationships(batch)
return capture.get_results()When benchmarking GraphRAG systems, we track metrics across multiple dimensions:
Processing Metrics:
Storage Metrics:
Query Performance:
Resource Utilization:
Here’s the thing about benchmarking—your test data needs to reflect reality. We’ve learned this the hard way. Generic synthetic data might give you nice charts, but it won’t prepare you for production’s curveballs.
def create_graphrag_test_dataset(size="medium", domain="technical"):
"""
Generate realistic test datasets for GraphRAG benchmarking.
Args:
size: 'small' (~100 docs), 'medium' (~1K docs), 'large' (~10K docs)
domain: Type of content to generate
Returns:
TestDataset with documents, expected entities, and relationships
"""
dataset_configs = {
"small": {
"documents": 100,
"avg_doc_length": 2000,
"entity_density": 10, # entities per doc
"relationship_density": 2.5 # relationships per entity
},
"medium": {
"documents": 1000,
"avg_doc_length": 3000,
"entity_density": 15,
"relationship_density": 3.0
},
"large": {
"documents": 10000,
"avg_doc_length": 3500,
"entity_density": 20,
"relationship_density": 3.5
}
}
config = dataset_configs[size]
documents = []
# Generate documents with realistic complexity
for i in range(config["documents"]):
doc = generate_document(
length=config["avg_doc_length"],
entity_count=config["entity_density"],
domain=domain
)
documents.append(doc)
# Create expected relationships based on entity overlap
expected_relationships = generate_relationship_patterns(
documents,
density=config["relationship_density"]
)
return TestDataset(
documents=documents,
expected_entities=extract_ground_truth_entities(documents),
expected_relationships=expected_relationships,
metadata={
"size": size,
"domain": domain,
"total_chunks_estimate": estimate_chunks(documents)
}
)Let’s start with the harsh truth. Here’s what performance looks like for a typical unoptimized GraphRAG implementation:
| Operation | Small Dataset (100 docs) | Medium Dataset (1K docs) | Large Dataset (10K docs) |
|---|---|---|---|
| Document Processing | 95.5 seconds | 25 minutes | 6.5 hours |
| Entity Extraction | 3.2 minutes | 45 minutes | 9 hours |
| Vector Storage | 45 seconds | 8 minutes | 1.5 hours |
| Graph Construction | 2.5 minutes | 35 minutes | 8.5 hours |
| Total Time | 6.8 minutes | 1.9 hours | 25.5 hours |
Notice the superlinear scaling? That’s our enemy. By the time you hit 10,000 documents, you’re looking at over a day of processing. Scale that to enterprise levels, and you’re measuring in weeks.
The first optimization might surprise you with its simplicity—smarter chunking. Most systems use fixed-size chunks, breaking documents at arbitrary boundaries. This creates more chunks than necessary and disrupts semantic coherence.
class SemanticAwareChunker:
"""
Intelligent document chunking that preserves semantic boundaries
and reduces overall chunk count.
"""
def __init__(self,
min_size=200,
max_size=1000,
overlap=50):
self.min_size = min_size
self.max_size = max_size
self.overlap = overlap
def chunk_document(self, document):
"""
Create semantically coherent chunks from a document.
Returns:
List of chunks with metadata
"""
# First, identify natural boundaries
sections = self._identify_sections(document)
chunks = []
for section in sections:
# If section is small enough, keep it whole
if len(section.content) <= self.max_size:
chunks.append(Chunk(
content=section.content,
metadata={
'section': section.title,
'type': section.type,
'position': section.position
}
))
else:
# Break large sections at paragraph boundaries
sub_chunks = self._chunk_large_section(section)
chunks.extend(sub_chunks)
# Add overlap for context continuity
chunks = self._add_overlap(chunks)
return chunks
def _identify_sections(self, document):
"""Identify document structure and natural boundaries."""
# Look for headers, code blocks, lists, etc.
patterns = {
'header': r'^#{1,6}\s+(.+)$',
'code_block': r'```[\s\S]*?```',
'list': r'^\s*[-*+]\s+.+$',
'paragraph': r'\n\n'
}
sections = []
current_pos = 0
# Parse document structure
for match in re.finditer('|'.join(patterns.values()), document, re.MULTILINE):
section_type = self._identify_match_type(match, patterns)
sections.append(Section(
content=match.group(),
type=section_type,
position=current_pos
))
current_pos = match.end()
return sectionsThe impact? We typically see:
Here’s where things get interesting. GraphRAG systems often process items one at a time, creating massive overhead. Let’s fix that:
class BatchOptimizedProcessor:
"""
Batch processing optimization for GraphRAG pipelines.
Reduces overhead and improves throughput significantly.
"""
def __init__(self, vector_db, graph_db, llm_client):
self.vector_db = vector_db
self.graph_db = graph_db
self.llm_client = llm_client
# Adaptive batch sizes
self.vector_batch_size = 1000
self.entity_batch_size = 500
self.relationship_batch_size = 1000
def process_documents_batch(self, documents):
"""
Process documents with optimized batching at every stage.
"""
all_chunks = []
all_entities = []
all_relationships = []
# Stage 1: Batch document processing
for doc_batch in self._batch_items(documents, size=10):
chunks = self._process_document_batch(doc_batch)
all_chunks.extend(chunks)
# Stage 2: Batch entity extraction
for chunk_batch in self._batch_items(all_chunks, size=20):
entities, relationships = self._extract_entities_batch(chunk_batch)
all_entities.extend(entities)
all_relationships.extend(relationships)
# Stage 3: Batch storage operations
self._store_vectors_batch(all_chunks)
self._store_graph_batch(all_entities, all_relationships)
return len(all_chunks), len(all_entities), len(all_relationships)
def _extract_entities_batch(self, chunks):
"""
Extract entities from multiple chunks in a single LLM call.
"""
# Combine chunks for batch processing
combined_prompt = self._create_batch_extraction_prompt(chunks)
# Single LLM call for multiple chunks
response = self.llm_client.complete(
prompt=combined_prompt,
max_tokens=2000,
temperature=0.1
)
# Parse batch response
entities, relationships = self._parse_batch_response(response, chunks)
return entities, relationships
def _store_graph_batch(self, entities, relationships):
"""
Optimized batch storage for graph database.
"""
# Create entities in batches
for batch in self._batch_items(entities, self.entity_batch_size):
query = """
UNWIND $batch AS entity
CREATE (n:Entity {id: entity.id, name: entity.name})
SET n += entity.properties
"""
self.graph_db.run(query, batch=[e.to_dict() for e in batch])
# Create relationships with grouping to prevent conflicts
grouped_rels = self._group_relationships_by_type(relationships)
for rel_type, rels in grouped_rels.items():
for batch in self._batch_items(rels, self.relationship_batch_size):
query = f"""
UNWIND $batch AS rel
MATCH (a:Entity {{id: rel.source}})
MATCH (b:Entity {{id: rel.target}})
CREATE (a)-[r:{rel_type}]->(b)
SET r += rel.properties
"""
self.graph_db.run(query, batch=[r.to_dict() for r in batch])Results from batch optimization:
Figure 2: Optimization Techniques Comparison – This diagram shows the performance improvements from different optimization techniques across dataset sizes. Notice how some optimizations like Mix and Batch actually hurt performance at small scales but become increasingly valuable as data grows. The synergistic effects demonstrate that combining optimizations often yields better results than the sum of individual improvements.
GraphRAG’s graph database operations are particularly susceptible to lock contention. Here’s how we solve it:
class ParallelGraphProcessor:
"""
Parallel processing for graph operations with intelligent
conflict resolution and deadlock prevention.
"""
def __init__(self, graph_db, num_workers=4):
self.graph_db = graph_db
self.num_workers = num_workers
self.conflict_resolver = ConflictResolver()
def create_relationships_parallel(self, relationships):
"""
Create relationships in parallel while preventing deadlocks.
"""
# Group relationships to minimize conflicts
relationship_groups = self.conflict_resolver.partition_relationships(
relationships,
self.num_workers
)
with ThreadPoolExecutor(max_workers=self.num_workers) as executor:
futures = []
for group_id, group in enumerate(relationship_groups):
future = executor.submit(
self._process_relationship_group,
group,
group_id
)
futures.append(future)
# Collect results and handle any conflicts
total_created = 0
conflicts = []
for future in as_completed(futures):
try:
created, group_conflicts = future.result()
total_created += created
conflicts.extend(group_conflicts)
except Exception as e:
self._handle_processing_error(e)
# Retry conflicts serially
if conflicts:
conflict_created = self._process_conflicts(conflicts)
total_created += conflict_created
return total_created
def _process_relationship_group(self, relationships, group_id):
"""
Process a group of non-conflicting relationships.
"""
created = 0
conflicts = []
# Use a dedicated session for this group
with self.graph_db.session() as session:
for rel in relationships:
try:
session.run("""
MATCH (a:Entity {id: $source_id})
MATCH (b:Entity {id: $target_id})
CREATE (a)-[r:RELATES_TO]->(b)
SET r += $properties
""", source_id=rel.source, target_id=rel.target,
properties=rel.properties)
created += 1
except TransactionError:
conflicts.append(rel)
return created, conflictsDon’t forget about query performance! Here’s how to optimize the retrieval side:
class OptimizedGraphRAGRetriever:
"""
Optimized retrieval for GraphRAG queries with intelligent
traversal strategies and caching.
"""
def __init__(self, vector_db, graph_db, cache_size=1000):
self.vector_db = vector_db
self.graph_db = graph_db
self.cache = LRUCache(cache_size)
def retrieve(self, query, max_results=10):
"""
Retrieve relevant context using optimized dual retrieval.
"""
# Check cache first
cache_key = self._generate_cache_key(query)
if cache_key in self.cache:
return self.cache[cache_key]
# Phase 1: Vector search with pre-filtering
vector_results = self._optimized_vector_search(query, max_results * 2)
# Phase 2: Targeted graph expansion
graph_context = self._bounded_graph_expansion(
vector_results,
max_depth=2,
max_nodes=50
)
# Phase 3: Intelligent merging
merged_context = self._merge_contexts(vector_results, graph_context)
# Cache the result
self.cache[cache_key] = merged_context
return merged_context
def _bounded_graph_expansion(self, seed_nodes, max_depth, max_nodes):
"""
Perform bounded graph traversal to prevent explosion.
"""
expanded_nodes = set()
current_layer = seed_nodes
nodes_added = len(seed_nodes)
for depth in range(max_depth):
if nodes_added >= max_nodes:
break
next_layer = []
# Batch graph queries for efficiency
query = """
UNWIND $nodes AS node_id
MATCH (n:Entity {id: node_id})-[r]-(connected)
WHERE NOT connected.id IN $excluded
RETURN connected, r, node_id
LIMIT $limit
"""
results = self.graph_db.run(
query,
nodes=[n.id for n in current_layer],
excluded=list(expanded_nodes),
limit=max_nodes - nodes_added
)
for record in results:
connected_node = record['connected']
if connected_node.id not in expanded_nodes:
next_layer.append(connected_node)
expanded_nodes.add(connected_node.id)
nodes_added += 1
current_layer = next_layer
return expanded_nodesHere’s what nobody tells you about GraphRAG scaling—it’s not linear, and that’s both a curse and an opportunity. Let’s look at how different components scale:
Figure 3: Resource Utilization Profiles – This diagram illustrates how different optimization strategies affect resource usage patterns. Memory usage shows distinct patterns, from baseline’s linear growth to the more efficient scaling of optimized approaches. CPU utilization varies from single-core bottlenecks in baseline implementations to balanced multi-core usage with full optimizations.
Memory usage in GraphRAG can explode if you’re not careful. Here’s how to keep it under control:
class MemoryAwareGraphRAGProcessor:
"""
Memory-conscious processing for large-scale GraphRAG.
"""
def __init__(self, memory_limit_gb=8):
self.memory_limit_bytes = memory_limit_gb * 1024 * 1024 * 1024
self.current_usage = 0
def process_with_memory_management(self, documents):
"""
Process documents while respecting memory constraints.
"""
processed = 0
buffer = []
for doc in documents:
estimated_size = self._estimate_memory_usage(doc)
# Check if we need to flush
if self.current_usage + estimated_size > self.memory_limit_bytes:
self._flush_buffer(buffer)
buffer = []
self.current_usage = 0
gc.collect() # Force garbage collection
# Process document
processed_doc = self._process_document(doc)
buffer.append(processed_doc)
self.current_usage += estimated_size
processed += 1
# Periodic memory health check
if processed % 100 == 0:
self._check_memory_health()
# Don't forget the last batch
if buffer:
self._flush_buffer(buffer)
return processedIn real-world graphs, you’ll encounter “supernodes”—entities with thousands of relationships. These can bring your system to its knees. Here’s how we handle them:
def handle_supernode_relationships(graph_db, supernode_threshold=1000):
"""
Special handling for highly connected nodes that can cause
performance degradation.
"""
# Identify supernodes
supernode_query = """
MATCH (n)
WITH n, size((n)--()) as degree
WHERE degree > $threshold
RETURN n.id as node_id, degree
ORDER BY degree DESC
"""
supernodes = graph_db.run(supernode_query, threshold=supernode_threshold)
# Process supernode relationships differently
for node in supernodes:
# Create a virtual node to distribute load
virtual_node_query = """
MATCH (super:Entity {id: $node_id})
CREATE (virtual:VirtualNode {
original_id: $node_id,
partition: $partition
})
CREATE (super)-[:HAS_PARTITION]->(virtual)
"""
# Distribute relationships across virtual nodes
partition_count = max(1, node['degree'] // supernode_threshold)
for partition in range(partition_count):
graph_db.run(virtual_node_query,
node_id=node['node_id'],
partition=partition)Production GraphRAG systems need to handle continuous updates. Here’s a pattern that works:
class IncrementalGraphRAGUpdater:
"""
Handle real-time updates to GraphRAG systems without
full reprocessing.
"""
def __init__(self, vector_db, graph_db):
self.vector_db = vector_db
self.graph_db = graph_db
self.update_queue = Queue()
self.processing = True
def add_document(self, document):
"""
Add a new document to the GraphRAG system incrementally.
"""
# Process the document
chunks = self._chunk_document(document)
entities, relationships = self._extract_entities(chunks)
# Update vector store
embeddings = self._generate_embeddings(chunks)
self.vector_db.add_vectors(embeddings)
# Update graph with conflict detection
existing_entities = self._check_existing_entities(entities)
new_entities = [e for e in entities if e.id not in existing_entities]
# Add new entities
if new_entities:
self.graph_db.create_entities(new_entities)
# Add relationships with deduplication
self._add_relationships_incremental(relationships)
# Update indices
self._refresh_indices()Not all optimizations are created equal, and the right strategy depends on your specific use case. Here’s a decision framework:
Figure 4: Progressive Optimization Strategy – This diagram presents a phased approach to implementing GraphRAG optimizations. Start with foundational techniques that provide immediate benefits, then layer on scale enhancements as your dataset grows. Advanced techniques should be reserved for large-scale deployments where their overhead is justified by the performance gains.
A Fortune 500 technology company implemented GraphRAG for their internal knowledge management system, processing over 50,000 technical documents. Their journey offers valuable lessons.
Initial State:
Optimization Journey:
Phase 1 – Foundation (Week 1-2):
Phase 2 – Scale Enhancements (Week 3-4):
Phase 3 – Advanced Optimizations (Week 5-6):
Final Results:
“The progressive approach was key,” explains their lead engineer. “Each optimization built on the previous ones, and we could measure the impact at each step.”
A financial services firm used GraphRAG to connect regulatory documents, internal policies, and audit reports. Their unique challenge was the density of relationships—financial regulations reference each other extensively.
Unique Challenges:
Optimization Focus: They prioritized query-time performance over ingestion speed:
# Their custom caching strategy
class ComplianceGraphCache:
def __init__(self, ttl_seconds=3600):
self.cache = {}
self.ttl = ttl_seconds
self.access_log = [] # For audit trails
def get_regulatory_context(self, query, user_id):
cache_key = f"{query}:{user_id}"
# Log access for compliance
self.access_log.append({
'user': user_id,
'query': query,
'timestamp': datetime.now()
})
# Check cache with TTL
if cache_key in self.cache:
entry = self.cache[cache_key]
if time.time() - entry['timestamp'] < self.ttl:
return entry['data']
# Cache miss - fetch and cache
context = self._fetch_context(query)
self.cache[cache_key] = {
'data': context,
'timestamp': time.time()
}
return contextResults:
The GraphRAG optimization landscape is evolving rapidly. Here are promising directions we’re exploring:
1. Adaptive Optimization Selection Systems that automatically choose optimization strategies based on workload characteristics:
class AdaptiveGraphRAGOptimizer:
"""
Self-tuning optimization system for GraphRAG.
"""
def analyze_workload(self, sample_documents):
"""
Analyze workload characteristics to recommend optimizations.
"""
metrics = {
'avg_doc_length': np.mean([len(d) for d in sample_documents]),
'entity_density': self._estimate_entity_density(sample_documents),
'relationship_complexity': self._analyze_relationships(sample_documents),
'query_patterns': self._analyze_query_log()
}
# Recommend optimizations based on analysis
recommendations = []
if metrics['avg_doc_length'] > 5000:
recommendations.append('semantic_chunking')
if metrics['entity_density'] > 20:
recommendations.append('extraction_batching')
if metrics['relationship_complexity'] > 3.5:
recommendations.append('mix_and_batch')
return recommendations2. Hardware-Accelerated Graph Processing Leveraging GPUs for graph operations is showing promising results:
3. Distributed GraphRAG For truly massive deployments, distribution is inevitable:
Optimizing GraphRAG systems for production isn’t just about making them faster—it’s about making them possible. The difference between an unoptimized system that takes days to process your knowledge base and an optimized one that completes in hours isn’t just convenience; it determines whether GraphRAG is viable for your use case at all.
Through our journey from baseline implementations to highly optimized systems, we’ve seen that the key to success lies in understanding where bottlenecks emerge and applying the right optimizations at the right scale. The 10-15x performance improvements we’ve demonstrated aren’t theoretical—they’re what separate proof-of-concept demos from production-ready systems.
As the GraphRAG ecosystem continues to mature, we’re seeing new optimization techniques emerge that push the boundaries even further. Whether through adaptive optimization selection, hardware acceleration, or distributed architectures, the future of GraphRAG performance looks bright. The key is to start with solid fundamentals and build up your optimization strategy as your system grows.
The teams that master these optimization techniques aren’t just building faster systems—they’re unlocking entirely new possibilities for AI applications that understand and navigate complex knowledge landscapes. In a world where the difference between insight and information overload often comes down to performance, these optimizations aren’t just nice to have; they’re essential for staying competitive.
This is a Servoy tutorial on how to optimize code performance. A while back, I had…
This is an object-oriented Servoy tutorial on how to use an object as a cache in…
This is an object-oriented Servoy tutorial on how to use function memoization with Servoy. Function memoization…
This is an object-oriented Servoy tutorial on how to use object-oriented programming in Servoy. Javascript’s core…
This is an object-oriented Servoy tutorial on how to use inheritance patterns in Servoy. I use…
This is an object-oriented Servoy tutorial on how to use prototypal inheritance in Servoy. When…