A database persists data so a digital twin can retrieve and use it for monitoring, analysis, and decisions. It sits between incoming data from sensors, enterprise systems, APIs, and people and the models that give those inputs context. Storage alone is not enough: fragmented or inconsistent data can make the twin unreliable. section 4.0 section 1.6
A relational database is a strong choice for reference data, asset hierarchies, configuration, and operational records. Its schema represents entities and their relationships, while transactions provide ACID guarantees: atomicity, consistency, isolation, and durability. Those guarantees help preserve integrity through errors or failures, but add latency and can limit horizontal scalability. High-volume sensor telemetry often needs a different storage type optimized for throughput. section 4.3.1
Query maintenance records
Store an industrial asset once, then link its work orders and tasks through their identifiers. A SQL query can follow those links to find tasks completed by a named technician on or before their scheduled date for a specified asset. The SQLite example runs the query from Python with sqlite3 and reads the results with pandas. section 4.3.1
Listing 4.3 An example ad hoc query written in SQL against data in a SQLite database
import sqlite3
import pandas as pd
conn = sqlite3.connect('maintenance.db') #1
query = '''
SELECT WT.DESCRIPTION, WT.COMPLETED_DATE, WT.COMPLETED_BY
FROM WORK_ORDER_TASK WT, WORK_ORDER W, ASSET A
WHERE WT.STATUS = 'COMPLETED'
AND WT.COMPLETED_BY = 'John Smith'
AND WT.COMPLETED_DATE <= W.SCHEDULED_DATE
AND WT.WORK_ORDER_ID = W.WORK_ORDER_ID
AND W.ASSET_ID = A.ASSET_ID
AND A.asset_id = 'F1'
'''
print("Tasks completed by John Smith on/before scheduled date for asset F1:")
results = pd.read_sql_query(query, conn) #2
print(results.to_string(index=False))
conn.close()
The listing provides the full SQL joins, filters, and Python calls for the maintenance query. section 4.3.1
Choose storage by data type and intended outcome rather than treating one database as the answer to every workload. Relational storage favors schema enforcement and consistency for transactional data; specialized analytical storage favors rapid ingestion and high-volume queries; object storage handles unstructured data. Compare latency, growth, consistency, total cost—including ingestion, compute, and transfer—and integration complexity. More specialized stores can improve fit while increasing the work of managing them. section 4.6
Table 4.2 Typical sources of different data types in a digital twin and how they are typically structured, integrated, and stored
|
Data type
|
Typical sources
|
Integration method
|
Structure
|
Storage technology
|
Considerations
|
|---|---|---|---|---|---|
|
Reference data
|
ERP, asset management
|
Batch, API
|
Relational
|
PostgreSQL, Memgraph
|
Update frequency, consistency
|
|
Time-series data
|
IoT sensors, SCADA
|
Streaming
|
Columnar
|
InfluxDB, Timestream
|
Volume retention, query patterns
|
|
Spatial data
|
GIS, surveys
|
Batch, API
|
Specialized
|
PostGIS, Memgraph
|
Complexity, query types, accuracy requirements
|
|
Derived data
|
Analytics, ML
|
Batch processing
|
Various
|
Feature stores, S3
|
Refresh frequency, serving requirements
|
|
Unstructured data
|
Cameras, documents
|
API, batch
|
Binary/text
|
S3, blob storage
|
Size, access patterns, processing needs
|
The table maps reference, time-series, spatial, derived, and unstructured data to typical sources, integration methods, and storage technologies. section 4.6
