Graph databases and time-series databases

In short: Graph databases store relationships between things as a network, time-series databases store measurements with timestamps; both are specialised for their data pattern.

In more detail: Relational databases are all-rounders. For certain data shapes there are specialised databases that are much faster or simpler for these tasks.

In Depth

Graph databases

Data consist of nodes (people, products), edges (relationships such as “knows”, “bought”) and properties. Queries such as “friends of friends” or “shortest path” are direct and fast where SQL would need many joins. Examples: Neo4j (query language Cypher), Amazon Neptune, Memgraph.

MATCH (a:Person {name:'Mia'})-[:KNOWS*2]-(b)
RETURN DISTINCT b.name

Use: social networks, recommendations, fraud detection, knowledge graphs, network topology.

Time-series databases

Data are measurements with timestamps: temperature, server load, share prices, sensors. Typical: very many writes, rare changes, queries over time ranges (average per hour, maximum of the week) and automatic deletion or condensing of old data (retention, downsampling). Examples: InfluxDB, TimescaleDB (PostgreSQL extension), Prometheus, ClickHouse.

SELECT time_bucket('1 hour', ts) AS hour, avg(value)
FROM measurements GROUP BY hour;

When is it worth it?

With small data volumes PostgreSQL is often entirely sufficient (with recursion/indexes, with the TimescaleDB extension for time series). Specialised databases pay off when relationship depth or data volume burst SQL. Every additional database brings operation, backups and knowledge with it.

Other types

Document databases (MongoDB), key-value (Redis), wide-column (Cassandra), vector databases (for embeddings and AI search), search engines (Elasticsearch). The choice follows the access pattern, not the trend.

See also: NoSQL databases, Prometheus, Redis, MongoDB