A Logbook Built for Voyages, Not a General Ledger

Opening Scene

A ship carries more than one book. The cargo manifest and accounts live in a general ledger, organized around goods and transactions. But navigation entries live in a dedicated logbook, structured specifically around time — every page a sequence, every entry ordered against the last, built for exactly the kind of writing and reading a voyage demands. Nobody would try to navigate from the cargo ledger, and nobody would try to reconcile accounts from the logbook. Each book is shaped for what it’s actually used for.

Time-series modelling faces the same choice: a general-purpose database, or one purpose-built for time.

In Plain English

A time-series database is purpose-built to store, ingest, and query timestamped data at high volume — optimized for appending new records in time order, compressing sequential data efficiently, and running time-windowed queries fast. A general-purpose database can absolutely store timestamped data too, and often should for smaller volumes or where time-series data lives alongside genuinely relational data it needs to be joined against. The real question isn’t which is “better” — it’s which fits your actual ingestion volume, query patterns, and retention needs.

The Old Way

Before time-series databases matured into a distinct, well-supported category, teams defaulted to whatever general-purpose database they already had, which worked right up until it didn’t:

Storing high-volume timestamped data in a general-purpose relational database worked fine at modest scale, but write throughput and query performance both degraded as data volume grew, since general-purpose indexing and storage engines weren’t optimized for the specific access patterns time-series data demands.
Retention and rollup logic had to be hand-built and manually maintained in a general-purpose database, where time-series-specific features like automatic downsampling and tiered retention simply didn’t exist natively.
Compression, covered in Article 12, is dramatically more effective when a storage engine is designed around the specific patterns sequential timestamped data exhibits, something a general-purpose row store wasn’t built to exploit.

The pattern that emerged was pragmatic: general-purpose databases remained a fine choice for smaller-scale or heavily-relational time-series needs, while purpose-built time-series databases earned their place wherever volume, retention complexity, or query performance genuinely demanded it.

What’s Changing (and Why AI Is the Reason)

AI-generated telemetry has pushed many organizations’ time-series volumes past the threshold where a general-purpose database remains comfortable, making the choice of a purpose-built time-series database less of a specialized decision and more of a mainstream one. What used to be a scale reached by only the largest operations is now common for teams running substantial AI infrastructure.
AI-assisted workload analysis can now examine actual query and ingestion patterns and recommend whether a general-purpose or time-series-specific database genuinely fits better, replacing what used to be a decision made largely on intuition or default habit with an evidence-based recommendation. This makes the choice more accessible to teams without deep time-series database expertise of their own.
AI agents that need to query time-series data directly benefit from time-series databases’ more predictable, purpose-built query semantics — time-windowed aggregation, automatic downsampling — which are easier for an agent to reason about and generate correct queries against than equivalent hand-rolled logic in a general-purpose system. This connects to the query-generation reliability theme running throughout this series.

The Metaphor, Fully Extended

Ship’s Chronometer & Logbook Element	Time-Series Modelling Concept
The general ledger, organized around cargo and accounts	A general-purpose database, storing many kinds of data including some time-series
The dedicated logbook, structured specifically around sequential time	A purpose-built time-series database, optimized for timestamped data’s specific patterns
The logbook’s built-in structure for daily, weekly, and monthly summaries	A time-series database’s native support for downsampling and retention tiers
The cargo ledger’s transaction-focused organization, unsuited to navigation	A general-purpose database’s indexing, unsuited to high-volume time-windowed queries
The captain deciding which book to reach for based on the actual question being asked	Choosing between database types based on real ingestion volume and query patterns, not habit

For Beginners: What to Actually Do

Learn to recognize the signs that a general-purpose database is straining under time-series workload — slow time-windowed queries, ballooning storage, hand-built retention logic.
Practice framing the database choice around actual ingestion volume and query patterns, not as a binary “which is better” question.
Get familiar with at least one purpose-built time-series database’s basic query syntax, since its idioms differ meaningfully from general-purpose SQL.
Recognize that keeping time-series data in a general-purpose database alongside relational data it needs to be joined against is often a legitimate, deliberate choice, not a mistake.

For Practitioners and Leaders: The Deeper Layer

Use AI-assisted workload analysis to evaluate your actual ingestion and query patterns before committing to a database migration in either direction.
Set explicit volume and query-performance thresholds that trigger a re-evaluation of your time-series database choice, rather than reacting only after performance visibly degrades.
Weigh the operational cost of running and maintaining a specialized time-series database against the genuine performance and retention benefits it provides for your specific scale.
Prepare your time-series infrastructure for AI agents as direct query consumers, since a purpose-built database’s more predictable query semantics tend to produce more reliable AI-generated queries.

Quick Recap

Time-series databases are purpose-built for high-volume, timestamped data’s specific ingestion and query patterns; general-purpose databases remain a legitimate choice at smaller scale or where relational joins matter more.
The right choice depends on real ingestion volume, query patterns, and retention needs, not a general notion of which database is “better.”
AI-generated telemetry volume has pushed more organizations toward needing purpose-built time-series databases than in the past.
AI-assisted workload analysis can now recommend the right database choice based on actual evidence rather than habit or intuition.

Where This Fits in the Series

This article closes the series’ core techniques block with a foundational infrastructure choice. Article 10 moves into production concerns, starting with retention policies and tiered storage.