Understanding Time Series and Graph Databases: Internals

and System Design Considerations

1. Introduction to Specialized Database Systems

Modern data landscapes necessitate specialized database systems to manage and

derive value from diverse data types efficiently. While traditional relational databases
remain foundational, their limitations in handling specific data characteristics and
query patterns have led to the emergence of purpose-built solutions. Among these,
Time Series Databases (TSDBs) and Graph Databases (GDBs) stand out for their
optimized architectures tailored to chronological data and interconnected
relationships, respectively. This report delves into the core principles, internal
mechanisms, and system design considerations for both TSDBs and GDBs, providing a
comprehensive understanding essential for architectural decisions and high-level
design discussions.

2. Time Series Databases (TSDBs)

Time series data is fundamentally an ordered sequence of information, characterized

by observations collected over continuous, often equally spaced, time intervals.1 Time
serves as the central distinguishing attribute, differentiating it from cross-sectional
data (collected at a single point in time) or pooled data (a combination of both).1 Key
characteristics of time series data include its arrival in time order, and its classification
into "metrics" (regular intervals) or "events" (irregular intervals).1 Patterns such as
trends (continuous directional change), seasonality (fixed-frequency influences),
cycles (non-fixed frequency influences), and anomalies (unusual changes) are
commonly observed within time series datasets.1
2.1. Core Principles and Data Model

A Time Series Database (TSDB) is a specialized database system explicitly designed

for storing and retrieving time-stamped data points.2 Its primary function is to manage
data points linked to timestamps, optimizing for fast data ingestion and retrieval
crucial for large volumes of chronological data.3 Unlike relational databases that rely
on rigid schemas and tabular structures, TSDBs employ a more flexible data modeling
strategy centered on optimizing storage and query performance for time-stamped
information.4 This adaptability facilitates easier scalability and the ability to store
various data types without extensive alterations to the database structure.4

TSDBs organize data chronologically, providing a historical record of events or

measurements. The data itself can be numerical, categorical, or binary, serving
diverse analytical needs.3 They are optimised for high-performance writes, supporting
rapid ingestion of large volumes of data from sources like sensors, logs, or financial
systems.3

2.2. Internal Architecture

The internal architecture of TSDBs is specifically engineered to handle the unique

demands of time-series data, emphasizing efficient ingestion, storage, indexing, and
compression.

2.2.1. Data Ingestion

TSDBs are designed for high write throughput, a critical feature given the continuous
and high-rate generation of time-series data from sources like IoT devices, servers,
and financial markets.5 To manage this, they often employ data buffering to handle
temporary spikes in ingestion rates and data partitioning to distribute data across
multiple nodes, enhancing performance and scalability.5 For example, TimescaleDB,
built as a PostgreSQL extension, significantly improves ingestion throughput by
switching from bulk

INSERTS to COPY operations, and by allowing disabling synchronous replication and

fsync for use cases where temporary data loss is acceptable.7 InfluxDB's architecture
includes a Router that parses incoming data and routes it to Ingesters, replicating
data to multiple Ingesters for write durability. Ingesters process this data, make it
available for querying, and maintain a short-term Write-Ahead Log (WAL) to prevent
data loss.8

2.2.2. Storage Mechanisms

TSDBs utilise specialised storage structures, often columnar formats, to efficiently

manage sequences of data points over time.3 This columnar storage means data for
each time series is stored in contiguous blocks, which improves both compression and
retrieval.3
●​ Write-Ahead Log (WAL): The WAL ensures data durability by retaining data
during system restarts. When a write request is received, it's appended to the
WAL file and then written to disk using fsync() before the in-memory cache is
updated. This guarantees data safety even in unexpected failures.10
●​ Cache: An in-memory copy of data points currently in the WAL, the cache
organises points by series key (measurement, tag set, field key) and stores
uncompressed data. Queries execute on a copy of this cache, ensuring that
ongoing writes do not affect query results.10
●​ Time-Structured Merge Tree (TSM): InfluxDB uses a TSM data format for
efficient compaction and storage. TSM files store compressed series data in a
columnar format, grouping field values by series key and ordering them by time.
This allows the storage engine to store only differences (deltas) between values,
improving efficiency.10
●​ Apache Parquet: InfluxDB 3 leverages Apache Parquet format in its Object Store.
Each Parquet file represents a partition, a logical grouping of data, which is
sorted, encoded, and compressed.8
●​ Hypertables and Chunks (TimescaleDB): TimescaleDB introduces
"hypertables" as an abstraction of a single continuous table. Internally,
hypertables are automatically split into "chunks" based on time intervals and
optionally other partitioning keys (e.g., device ID). Each chunk is a standard
PostgreSQL table. This partitioning strategy allows the query planner to minimize
 the data scanned for a query, as it only needs to access relevant chunks.11
TimescaleDB's Hypercore engine uses a hybrid row-columnar storage: recent
data is kept in row-based storage for fast inserts, while older chunks are
automatically compressed into columnar storage for analytical performance and
storage efficiency.12

2.2.3. Indexing Strategies

Time series indexing organizes and optimizes time-stamped data for efficient
querying and retrieval, prioritizing the timestamp as the primary dimension.14
●​ Time-Based Indexing: Databases like InfluxDB use a Time Series Index (TSI) to
store series keys grouped by measurement, tag, and field, ensuring fast queries
even as data cardinality grows. This allows quick answers to questions about
existing measurements, tags, and fields, and specific series keys given these
parameters.9 TimescaleDB automatically creates indexes on time (descending) for
all hypertables, and on space parameters and time for those with space
partitions.11
●​ Tag-Based Indexing: Many TSDBs support secondary indexes on tags (e.g.,
sensor IDs) to speed up queries that filter by specific attributes in addition to time
ranges.9 This is crucial for filtering data by various attributes, such as​
account_id and timestamp in a logging scenario.7

2.2.4. Data Compression

Compression is a cornerstone feature in TSDBs, significantly reducing storage

requirements and enhancing query speed for time-series data.5
●​ Techniques: Common compression algorithms include delta encoding (storing
differences between consecutive values), run-length encoding (for repeated
values), and dictionary compression (replacing recurring patterns with shorter
representations).5 More advanced strategies like Gorilla compression are effective
for floating-point numbers.17
●​ Optimization: Compression algorithms exploit the temporal locality and value
correlation inherent in time-series data.18 For instance, TimescaleDB's Hypercore
 compresses chunks into columnar storage, achieving over 90% compression and
optimizing analytical queries.13 This reduction in data size directly translates to
faster query performance by minimizing the amount of data that needs to be
read.15

2.3. System Design Considerations for TSDBs

Designing systems with TSDBs involves careful consideration of scalability, high

availability, and performance optimization.

2.3.1. Scalability and High Availability

TSDBs are built to handle massive data volumes and high ingestion rates.
●​ Horizontal Scaling: Many TSDBs, like InfluxDB, are designed to scale horizontally
by distributing data across multiple servers or clusters.3 This involves partitioning
(or sharding) data into smaller chunks across different nodes, which improves
response time and avoids total service outages by distributing risk.21
●​ Vertical Scaling: While horizontal scaling adds more nodes, vertical scaling
involves increasing the computing power (CPU, RAM, disk) of a single machine.6
TimescaleDB, being a PostgreSQL extension, benefits from PostgreSQL's vertical
scalability, while also offering horizontal scaling capabilities through its chunking
mechanism and cloud deployments.6
●​ Replication: High availability is achieved through data replication across nodes.
For example, InfluxDB Enterprise uses clustering to provide fault tolerance and
availability, where data is replicated across multiple data nodes. If one node
becomes unavailable, data can be accessed from an alternate replica.20 Neo4j HA
also uses master-slave replication, with reads scaling linearly across slaves and
writes coordinated by the master.23
●​ Disaster Recovery: Managed TSDB services often include automatic backups
and point-in-time recovery (PITR) features. For instance, Timescale Cloud uses
pgBackRest for automatic backups and offers self-initiated PITR.13
2.3.2. Performance Optimization

Beyond core architecture, TSDBs employ several features to enhance query

performance and manage data lifecycle.
●​ Continuous Queries/Aggregates: Many TSDBs support continuous aggregates
(or materialized views), which precompute and store aggregate data
incrementally in the background.13 This shifts computation from query time to
ingestion time, dramatically reducing query latency, especially for dashboards
and analytical reports that frequently query aggregated data.15
●​ Downsampling and Rollups: As time-series data ages, its relevance to the
current system state often decreases. TSDBs offer downsampling capabilities to
reduce data granularity by rolling up documents within fixed time intervals into
summary documents (e.g., storing min, max, sum, count for each metric). This
trades resolution for storage size and can be integrated with data retention
policies to manage data volume and cost.6
●​ Data Retention Policies: TSDBs typically include built-in data retention policies
that automatically expire or downsample older data, reducing storage costs and
simplifying data management.3
●​ Query Optimization: Techniques like chunk exclusion (in TimescaleDB, where
irrelevant chunks are skipped based on query predicates) and SkipScan (for
faster DISTINCT queries) significantly improve query performance.7

2.4. Use Cases for TSDBs

TSDBs are particularly suited for applications dealing with continuous data streams
and time-sensitive analysis.
●​ Internet of Things (IoT): IoT devices generate continuous streams of
time-stamped data (e.g., smart thermostats, industrial sensors). TSDBs store and
analyze this data for smart homes, industrial automation, and environmental
monitoring, enabling real-time anomaly detection and performance tracking.2
●​ DevOps and System Monitoring: TSDBs are widely used to monitor IT
infrastructure and applications by collecting metrics like CPU usage, memory
consumption, and network throughput. They enable real-time performance
visualization, anomaly detection (e.g., spikes in server load), and capacity
 planning.2 Tools like Prometheus and Grafana often integrate with TSDBs for
visualization and alerting.2
●​ Financial Markets: TSDBs are critical for processing and analyzing
high-frequency data in financial markets, supporting algorithmic trading, risk
management, and market analysis by identifying trends and anomalies in
milliseconds.2
●​ Other Applications: This includes healthcare (monitoring patient vitals),
scientific research (climate modeling, astronomical observations), and business
analytics (tracking customer behavior, sales trends).26

3. Graph Databases (GDBs)

Graph databases are non-relational (NoSQL) database systems that prioritize

relationships between data points, using graph structures (nodes, edges, and
properties) for semantic queries.30 This contrasts sharply with relational databases,
which organize data into rigid tables and represent relationships implicitly through
foreign keys, requiring explicit

JOIN operations at runtime.30

3.1. Core Principles and Data Model

The fundamental components of a graph data model are:

●​ Nodes (Entities): Nodes represent discrete objects or entities within a domain,
analogous to records or rows in a relational database. They can have zero or more
labels to classify them (e.g., Person, Movie), which can be added or removed
during runtime to mark temporary states.32
●​ Edges (Relationships): Edges, also called relationships, are the lines connecting
nodes, explicitly representing the connections between them. Relationships
always have a direction and must have a type (e.g., ACTED_IN). They are a key
concept, as they are not directly implemented in relational or document models.32
Relationships are first-class citizens in a graph database, stored directly
alongside the data points they connect, which fundamentally changes how
 systems handle connected data.34
●​ Properties: Both nodes and relationships can have properties, which are
key-value pairs that describe their attributes (e.g., name: 'Tom Hanks', roles:
['Forrest'] on an ACTED_IN relationship). Properties can hold various data types,
including numbers, strings, booleans, or homogeneous lists.32

Graph databases often feature a flexible schema design, allowing for an evolutionary
approach to data modeling. New nodes, properties, and relationships can be added
without altering existing data, while still providing tools for data quality control.34

3.2. Internal Architecture

The internal architecture of GDBs is optimized for traversing complex relationships, a

core differentiator from other database types.

3.2.1. Node and Edge Storage

GDBs store data as a network of entities and relationships, explicitly storing both the
entity and relationship data rather than references.33 This direct storage of
relationships allows for rapid navigation between entities without needing to
dynamically calculate connections.33
●​ Native Graph Storage: Some GDBs, like Neo4j, use "native" graph storage
specifically designed to store and manage graphs. This involves distributing
graphs across several record files (e.g., one for nodes, one for relationships, one
for properties), composed of fixed-size records.36 Each node record is
lightweight, primarily pointing to lists of its relationships, labels, and properties.37
●​ Index-Free Adjacency: A key performance aspect in native graph databases is
"index-free adjacency." This means connected nodes physically point to each
other in the database, allowing direct physical RAM addresses and leading to very
fast retrieval.31 When a node is retrieved, directly related nodes are often stored in
cache, making subsequent lookups even faster.32 This avoids the overhead of
index lookups or hash joins needed in relational databases to reconstruct
relationships.34 This direct connection allows for immediate access, making
 multi-hop queries highly efficient.33

3.2.2. Indexing for Graph Traversals

While index-free adjacency handles direct connections, GDBs also use indexing for
efficient property lookups and query optimization.
●​ Property Indexes: Indexes can be created on frequently queried properties of
nodes or relationships to speed up data retrieval. This allows the database to
directly access required data instead of scanning the entire graph.42 For example,
indexing a 'name' property on nodes can make queries for specific names much
faster.42
●​ Schema and Constraints: Neo4j is "schema optional," meaning indexes and
constraints are not strictly necessary upfront but can be added later to improve
performance or enforce data rules.35 Indexes increase performance, while
constraints ensure data adheres to domain rules.35

3.2.3. Query Processing and Optimization

GDBs offer specialized query languages optimized for traversing relationships and
finding patterns in connected data, such as Cypher (Neo4j), Gremlin, or SPARQL.30
These languages prioritize relationship navigation and pattern matching, making them
natural fits for connected data problems.34
●​ Multi-Hop Queries: GDBs excel at multi-hop queries, where paths with multiple
relationships are traversed.33 Unlike relational databases that require increasingly
complex​
JOIN operations as relationships deepen, GDBs natively handle such
interconnected data structures at speed and scale.34 The performance tends to
remain steady even as the dataset grows because queries are restricted to a part
of the graph.31
●​ Query Rewriting: Query optimization involves transforming a query into an
equivalent form that executes more efficiently, reducing computational
complexity. This can involve rewriting nested subqueries to use more efficient
operations.42
●​ Caching: Storing frequently accessed data (nodes, edges, or query results) in
memory can dramatically improve query performance, especially for data that
doesn't change often.42
●​ Traversal Strategies: Traversal engines start at entry points (nodes) and follow
specific relationship types and directions defined in the query, tracking visited
nodes to avoid cycles and applying filters at each step.41 Strategies like
Breadth-First Search (BFS) and Depth-First Search (DFS) are chosen based on
query patterns.41
●​ Heuristics and Cost-Based Optimization: Query optimizers in GDBs can use
heuristics (syntax-based estimates) or cost-based optimization (utilizing
pre-computed statistics on data distribution) to determine the best graph
traversal plan.46

3.2.4. Common Graph Algorithms

Graph algorithms are powerful analytical tools that reveal hidden patterns and
structures within complex networks by traversing relationships.44 Many GDBs offer
built-in implementations of these algorithms.44
●​ Pathfinding Algorithms: These focus on finding the best way to move between
nodes, considering factors like distance, time, or cost (weights on relationships).44
○​ Dijkstra's Algorithm: Computes the shortest path in graphs with
non-negative weights.44
○​ A* Search: An informed search algorithm for weighted graphs, often used in
routing.44
○​ Breadth-First Search (BFS): Explores layer by layer, useful for finding the
shortest path in unweighted graphs.44
○​ Depth-First Search (DFS): Explores as far down a path as possible before
backtracking.44
●​ Centrality Algorithms: These measure the importance or influence of individual
nodes based on their position and connections.44
○​ PageRank: Measures influence based on the quality of incoming links from
important nodes, commonly used for ranking relevance.44
○​ Betweenness Centrality: Measures how often a node lies on the shortest
paths between other pairs of nodes, highlighting bottlenecks.44
●​ Community Detection Algorithms: These identify natural groups or clusters
within a network, where nodes are more densely connected to each other than to
 the rest of the network.44
○​ Louvain Modularity: Finds communities by optimizing network modularity.44
○​ Label Propagation (LPA): A fast, semi-supervised approach where nodes
adopt the majority label of their neighbors.44

3.3. System Design Considerations for GDBs

Designing systems with GDBs requires understanding their unique scaling challenges
and integration patterns.

3.3.1. Scalability and High Availability

While GDBs excel at relationship traversal, their scalability and high availability
strategies differ from other database types.
●​ Sharding: Sharding breaks down a large graph into smaller, manageable pieces
(shards) distributed across different machines.48 This allows handling enormous
datasets that a single server cannot manage. Sharding strategies can vary,
partitioning based on vertex properties or edge types.48 However, the inherent
interconnectivity of graph data complicates partitioning, as many edges may span
across different shards, potentially leading to increased network latency during
traversals.23
●​ Replication for HA: Neo4j, for example, uses a master-slave cluster architecture
for high availability. The full graph is replicated to each instance in the cluster,
ensuring data safety as long as one instance remains available. All write
operations are coordinated by the master, while reads can be distributed among
slave instances, allowing linear read scalability.23 This approach means that for
large datasets, the entire graph needs to reside on each machine, and for optimal
performance, it should ideally fit in memory to avoid expensive disk seeks.40
●​ Distributed Query Processing: To query a distributed graph, the system
identifies relevant shards, breaks the query into subqueries, and processes them
in parallel across machines. Results are then combined to form a complete
response.48 This parallel processing is crucial for large-scale traversals and graph
algorithms.48
3.3.2. Performance Optimization

Optimizing GDB performance focuses on efficient traversal and query execution for
complex relationships.
●​ Index-Free Adjacency: As discussed, this native processing capability is
fundamental to high-performance traversals, queries, and writes in GDBs.36
●​ Query Optimization Techniques: Beyond index-free adjacency, GDBs employ
query rewriting, indexing on properties, and caching of frequently accessed data
or query results to improve performance.42 For multi-hop queries, techniques like
pruning paths early when they fail conditions and parallelizing operations across
relationships are used.41
●​ Graph Algorithms: The efficient implementation of graph algorithms
(pathfinding, centrality, community detection) directly contributes to performance
by providing optimized ways to analyze complex network structures.44

3.4. Use Cases for GDBs

Graph databases excel in scenarios where complex, interconnected data queries are
central to the application's functionality.
●​ Social Networks: GDBs are ideal for managing and analyzing relationships
between users (e.g., friends, followers), enabling content personalization,
community detection, and influence analysis.49
●​ Fraud Detection: GDBs uncover suspicious networks of connected individuals or
transactions, identifying fraudulent activity by analyzing relationships that might
be missed by traditional databases.51 Examples include credit card fraud,
insurance fraud, and identity fraud.51
●​ Recommendation Systems: GDBs power personalized suggestions by analyzing
connections between users and items (e.g., purchases, browsing history, wish
lists), leading to more relevant and engaging recommendations.49
●​ Knowledge Graphs: These organize and link structured data for meaningful
insights, connecting entities like people, places, and events for better search
results or academic research.49
●​ Network and IT Operations: GDBs map and visualize network structures, aiding
in performance optimization, troubleshooting (e.g., identifying root causes of
incidents), and capacity planning.49
●​ Cybersecurity: Analyzing connections in network logs to detect threats, identify
attack vectors, or spot phishing attempts based on anomalous behavior.49

4. Comparison and Decision Criteria

Choosing between TSDBs and GDBs, or even against traditional relational/NoSQL

databases, depends heavily on the nature of the data, the complexity of relationships,
and the specific use cases.52

4.1. Time Series Databases vs. Relational Databases

Feature Relational Databases Time Series Databases

(RDBMS) (TSDBs)

Data Structure Tables (rows & columns) with Timestamped data, often
defined schemas and columnar, optimized for
relationships via sequences of data points 3
4
primary/foreign keys

Data Modeling Structured, rigid schema Flexible (schema-on-write),

(schema-on-write), optimized for time-stamped
normalization (1NF, 2NF, 3NF) data 4
4

Querying SQL, complex queries, JOIN Specialized query languages

operations across multiple (e.g., InfluxQL, Flux, PromQL)
tables 4 or SQL extensions
(TimescaleDB), optimized for
time-oriented queries (e.g.,
time-based window functions,
downsampling) 4
 Performance Can degrade with large Consistent performance with
datasets and complex JOINs 3 increasing time-stamped data
volume, optimized for
time-based queries 3

Scalability Challenges in horizontal Designed for horizontal

scaling due to data integrity scaling, high ingestion rates 3
focus, typically vertical scaling
3

Maintenance Requires structured routines Simplified with built-in

due to complex schemas and functionalities for automatic
relationships 3 data deletion/archiving 3

Primary Use Cases OLTP, structured data, high IoT, DevOps monitoring,
data integrity (e.g., financial financial markets, real-time
transactions, ERP) 4 analytics, log analysis 2

Key Differentiator Prioritizes data entities and Prioritizes time as the central
their integrity 33 attribute, optimized for
chronological data 1

Relational databases excel when ACID compliance and high data integrity are
paramount, or when working with highly structured data with limited relationships.33
However, they struggle with the volume and velocity of continuous data streams and
become inefficient for time-based aggregations over large ranges.6 TSDBs,
conversely, are purpose-built for these challenges, offering superior performance for
time-stamped data and reducing storage costs through compression.3

4.2. Graph Databases vs. Relational Databases

Feature Relational Databases Graph Databases (GDBs)

(RDBMS)

Data Structure Tabular format (rows & Network of entities (nodes)

columns), relationships as and relationships (edges) 33
foreign keys 33

Data Modeling Structured, rigid schema, Flexible schema

 normalization 4 (schema-optional),
relationship-centric 31

Querying SQL, JOIN statements to Graph query languages

33 (Cypher, Gremlin, SPARQL),
resolve relationships
direct traversal 33

Performance Degrades significantly with Consistent performance

increasing number of JOINs regardless of relationship
(multi-hop queries) 31 complexity or data size for
traversals (index-free
adjacency) 31

Scalability Primarily vertical scaling, Designed for horizontal

horizontal scaling is scaling, but sharding complex
challenging for complex graphs can be challenging 48
relationships 55

Ease of Use SQL can feel unnatural for Intuitive for connected data,
multi-hop queries 33 simple syntax for exploring
interconnections 33

Primary Use Cases ACID compliance, highly Complex data

structured data, limited interconnections, social
relationships (e.g., financial networks, fraud detection,
transactions, ERP) 33 recommendation systems,
knowledge graphs 33

Key Differentiator Prioritizes data entities 33 Prioritizes relationships

between entities 31

Graph databases are superior for use cases with complex, deeply interconnected data
because they explicitly store relationships, allowing for rapid traversal without costly
JOIN operations.33 This direct connection model provides significant performance
advantages for multi-hop queries and pattern matching.33 Relational databases, while
capable of representing relationships, incur performance penalties as the number of
joins increases, making them less suitable for highly interconnected, evolving data
models.34

4.3. Time Series Databases vs. Graph Databases

TSDBs and GDBs are both specialized NoSQL-era databases but serve distinct
purposes. TSDBs are optimized for data where time is the primary axis of organization
and analysis, focusing on high-volume, sequential data ingestion and time-based
queries.3 GDBs, on the other hand, are optimized for data where relationships and
connections between entities are paramount, excelling at traversing complex
networks.30

The decision between a TSDB and a GDB hinges on the primary nature of the data
and the most frequent query patterns. If the core problem involves analyzing changes
over time, trends, and anomalies in sequential measurements, a TSDB is the
appropriate choice. If the problem involves understanding connections, influence,
paths, and communities within a network of entities, a GDB is more suitable. It is not
uncommon for complex systems to utilize both, with a TSDB handling operational
metrics and a GDB managing user relationships or system dependencies.

5. Conclusions

Time Series Databases and Graph Databases represent powerful advancements in

specialized data management, each addressing specific challenges that traditional
relational databases often struggle with. TSDBs are engineered for the high-volume,
continuous ingestion and rapid time-based querying of chronological data, making
them indispensable for IoT, monitoring, and financial analytics. Their internal
architectures, featuring columnar storage, advanced compression techniques, and
time-partitioning mechanisms like hypertables and chunks, are meticulously designed
to optimize for append-only workloads and efficient range queries.

Graph Databases, conversely, redefine how relationships are managed, treating

connections as first-class citizens. Their property graph model, coupled with
"index-free adjacency," enables unparalleled performance for traversing complex,
multi-hop relationships, making them ideal for social networks, fraud detection, and
recommendation systems. While sharding presents unique challenges for GDBs due to
the interconnected nature of the data, replication strategies ensure high availability.

For high-level system design, the choice between these specialized databases is
dictated by the intrinsic nature of the data and the dominant query patterns. A
thorough understanding of their internal mechanisms, including data ingestion
pipelines, storage formats, indexing strategies, and query optimization techniques, is
crucial for designing scalable, performant, and resilient systems. Recognizing when to
leverage the strengths of a TSDB for temporal analysis versus a GDB for relational
exploration allows architects to build more efficient and insightful data-driven
applications.

Works cited

1.​ The Complete Guide to Time Series Data - Clarify, accessed on July 10, 2025,
https://www.clarify.io/learn/time-series-data
2.​ What is a Time Series Database? - Redis, accessed on July 10, 2025,
https://redis.io/nosql/timeseries-databases/
3.​ What Is a Time Series Database? How It Works + Use Cases - Timeplus, accessed
on July 10, 2025, https://www.timeplus.com/post/time-series-database
4.​ Time-Series Database vs Relational Database: Key Differences - Timeplus,
accessed on July 10, 2025,
https://www.timeplus.com/post/time-series-database-vs-relational
5.​ Time-Series Databases 101 - Number Analytics, accessed on July 10, 2025,
https://www.numberanalytics.com/blog/time-series-databases-ultimate-guide
6.​ Time-Series Database: An Explainer - TigerData, accessed on July 10, 2025,
https://www.tigerdata.com/blog/time-series-database-an-explainer
7.​ How TimescaleDB helped us scale analytics and reporting - The Cloudflare Blog,
accessed on July 10, 2025, https://blog.cloudflare.com/timescaledb-art/
8.​ InfluxDB 3 storage engine architecture | InfluxDB Cloud Dedicated ..., accessed on
July 10, 2025,
https://docs.influxdata.com/influxdb3/cloud-dedicated/reference/internals/storag
e-engine/
9.​ Time series database explained | InfluxData, accessed on July 10, 2025,
https://www.influxdata.com/time-series-database/
10.​InfluxDB storage engine | InfluxDB OSS v2 Documentation, accessed on July 10,
2025, https://docs.influxdata.com/influxdb/v2/reference/internals/storage-engine/
11.​ docs.timescale.com-content/introduction/architecture.md at master ..., accessed
on July 10, 2025,
https://github.com/timescale/docs.timescale.com-content/blob/master/introducti
on/architecture.md
12.​TigerData Documentation | Hypertables and chunks - Docs, accessed on July 10,
2025, https://docs.tigerdata.com/api/latest/hypertable/
13.​TigerData Documentation | Hypertables, accessed on July 10, 2025,
https://docs.tigerdata.com/use-timescale/latest/hypertables/
14.​What is time series indexing, and why is it important? - Milvus, accessed on July
10, 2025,
https://milvus.io/ai-quick-reference/what-is-time-series-indexing-and-why-is-it-i
mportant
15.​PostgreSQL + TimescaleDB: 1,000x Faster Queries, 90 % Data Compression, and
Much More | TigerData, accessed on July 10, 2025,
https://www.tigerdata.com/blog/postgresql-timescaledb-1000x-faster-queries-9
 0-data-compression-and-much-more
16.​7 Cutting-Edge Time Series Database Examples For 2024 - Timeplus, accessed on
July 10, 2025, https://www.timeplus.com/post/time-series-database-example
17.​What Is Data Compression and How Does It Work? | TigerData - TimescaleDB,
accessed on July 10, 2025,
https://www.tigerdata.com/learn/what-is-data-compression-and-how-does-it-w
ork
18.​Time-Series Compression Algorithms - QuestDB, accessed on July 10, 2025,
https://questdb.com/glossary/time-series-compression-algorithms/
19.​timescale/timescaledb: A time-series database for high-performance real-time
analytics packaged as a Postgres extension - GitHub, accessed on July 10, 2025,
https://github.com/timescale/timescaledb
20.​InfluxDB Enterprise features, accessed on July 10, 2025,
https://docs.influxdata.com/enterprise_influxdb/v1/features/
21.​What is Database Sharding? - Shard DB Explained - AWS, accessed on July 10,
2025, https://aws.amazon.com/what-is/database-sharding/
22.​adamringhede/influxdb-ha: High-availability and horizontal scalability for InfluxDB
- GitHub, accessed on July 10, 2025,
https://github.com/adamringhede/influxdb-ha
23.​Neo4j - Difference between High Availability and Distributed Mechanism? - Stack
Overflow, accessed on July 10, 2025,
https://stackoverflow.com/questions/35982619/neo4j-difference-between-high-a
vailability-and-distributed-mechanism
24.​Understanding Neo4j Scalability, accessed on July 10, 2025,
https://go.neo4j.com/rs/710-RRC-335/images/Understanding%20Neo4j%20Scala
bility%282%29.pdf
25.​Downsampling a time series data stream | Elastic Docs, accessed on July 10,
2025,
https://www.elastic.co/docs/manage-data/data-store/data-streams/downsamplin
g-time-series-data-stream
26.​Time Series Database (TSDB): A Guide With Examples - DataCamp, accessed on
July 10, 2025, https://www.datacamp.com/blog/time-series-database
27.​Data Pipeline Visualization Mastery - Number Analytics, accessed on July 10,
2025,
https://www.numberanalytics.com/blog/data-pipeline-visualization-tools-guide
28.​How To Deploy A Telegraf, InfluxDB And Grafana Stack On Debian VPS, accessed
on July 10, 2025,
https://blog.radwebhosting.com/how-to-deploy-a-telegraf-influxdb-and-grafana
-stack-on-debian-vps/
29.​Get started with Grafana and InfluxDB, accessed on July 10, 2025,
https://grafana.com/docs/grafana/latest/getting-started/get-started-grafana-influ
xdb/
30.​www.puppygraph.com, accessed on July 10, 2025,
https://www.puppygraph.com/blog/graph-database-vs-relational-database#:~:te
xt=Graph%20databases%20focus%20on%20the,databases%20organize%20dat
 a%20into%20tables.
31.​Graph Database Architecture and Use Cases - XenonStack, accessed on July 10,
2025, https://www.xenonstack.com/insights/graph-database
32.​Graph database - Wikipedia, accessed on July 10, 2025,
https://en.wikipedia.org/wiki/Graph_database
33.​Graph vs Relational Databases - Difference Between Databases - AWS, accessed
on July 10, 2025,
https://aws.amazon.com/compare/the-difference-between-graph-and-relational
-database/
34.​Graph Database vs. Relational Database: What's The Difference? - Neo4j,
accessed on July 10, 2025,
https://neo4j.com/blog/graph-database/graph-database-vs-relational-database/
35.​Graph database concepts - Getting Started - Neo4j, accessed on July 10, 2025,
https://neo4j.com/docs/getting-started/appendix/graphdb-concepts/
36.​Graph Database Internals, accessed on July 10, 2025,
http://www.dl.edi-info.ir/Graph%20Database%20Internals.pdf
37.​Graph Databases for Beginners - Neo4j, accessed on July 10, 2025,
https://neo4j.com/wp-content/themes/neo4jweb/assets/images/Graph_Database
s_for_Beginners.pdf
38.​RDBMS & Graphs: Relational vs. Graph Data Modeling - Neo4j, accessed on July
10, 2025, https://neo4j.com/blog/developer/rdbms-vs-graph-data-modeling/
39.​1 Introduction - arXiv, accessed on July 10, 2025,
https://arxiv.org/html/2412.18143v1
40.​What is Neo4j Architecture? Can anyone explain the Neo4J ... - Quora, accessed
on July 10, 2025,
https://www.quora.com/What-is-Neo4j-Architecture-Can-anyone-explain-the-N
eo4J-Architecture-with-a-diagram
41.​How does a graph database perform graph traversals? - Milvus, accessed on July
10, 2025,
https://milvus.io/ai-quick-reference/how-does-a-graph-database-perform-graph
-traversals
42.​What is Query Optimization in Graph Databases? Techniques and Strategies -
Hypermode, accessed on July 10, 2025,
https://hypermode.com/blog/query-optimization
43.​Schema-Based Query Optimisation for Graph Databases - arXiv, accessed on
July 10, 2025, https://arxiv.org/pdf/2403.01863
44.​What Are the Different Types of Graph Algorithms & When to Use Them? - Neo4j,
accessed on July 10, 2025,
https://neo4j.com/blog/graph-data-science/graph-algorithms/
45.​Graph Algorithms: A Developer's Guide - PuppyGraph, accessed on July 10,
2025, https://www.puppygraph.com/blog/graph-algorithms
46.​Query Optimizer (Preview) :: GSQL Language Reference, accessed on July 10,
2025, https://docs.tigergraph.com/gsql-ref/4.2/querying/query-optimizer/
47.​Neptune Analytics algorithms - Neptune Analytics, accessed on July 10, 2025,
https://docs.aws.amazon.com/neptune-analytics/latest/userguide/algorithms.html
48.​Distributed Graph Database: The Ultimate Guide - PuppyGraph, accessed on July
10, 2025, https://www.puppygraph.com/blog/distributed-graph-database
49.​When To Use A Graph Database? 7 Areas To Know - PuppyGraph, accessed on
July 10, 2025, https://www.puppygraph.com/blog/when-to-use-graph-database
50.​10-weeks/Projects-Blogs/07-bigdata-databases/neo4j-architecture.md at master
- GitHub, accessed on July 10, 2025,
https://github.com/gopala-kr/10-weeks/blob/master/Projects-Blogs/07-bigdata-d
atabases/neo4j-architecture.md
51.​6 Graph Database Use Cases With Examples - PuppyGraph, accessed on July 10,
2025, https://www.puppygraph.com/blog/graph-database-use-cases
52.​Vector database vs. graph database: Understanding the differences | Elastic Blog,
accessed on July 10, 2025,
https://www.elastic.co/blog/vector-database-vs-graph-database
53.​What is a Graph Database? Use Cases and Advantages - Decube, accessed on
July 10, 2025, https://www.decube.io/post/graph-database-concept
54.​The Role of Graph Databases in Complex Data Relationships and Their
Comparison with Relational Approaches | by A | Medium, accessed on July 10,
2025,
https://medium.com/@jaguuai/the-role-of-graph-databases-in-complex-data-rel
ationships-and-their-comparison-with-relational-c7643aed0aa3
55.​Relational vs Non-relational Databases: Which to Choose? - Onix-Systems,
accessed on July 10, 2025,
https://onix-systems.com/blog/relational-vs-non-relational-databases
56.​Graph Database vs Relational Database: What to Choose? - NebulaGraph,
accessed on July 10, 2025,
https://www.nebula-graph.io/posts/graph-database-vs-relational-database