FAQs - Using TimescaleDB

    Owing to these advantages, TimescaleDB is currently deployed across a variety of industries, including manufacturing, energy, utilities, mining, oil and gas, finance, ad tech, smart spaces, and more. Use cases include complex monitoring and analytics; predicting the performance and behavior of applications, models, consumers and connected machines; powering operational analytical workflows and dashboards; and QA and performance testing.

    How do I write data?

    Just via normal SQL, but here are some insert examples.

    How do I read data?

    Just via normal SQL, but here are some query examples.

    How far can TimescaleDB scale?

    In our internal benchmarks on standard cloud VMs, we regularly test single-node TimescaleDB to hundreds of terabytes of data, while sustaining insert rates of 100-200k rows / second (1-2 million metric inserts / second). Multi-node TimescaleDB can scale to 10+ million metric inserts / second, and store petabytes of data. You can read more about for multi-node TimescaleDB.

    TimescaleDB is designed to combine the scalability of popular NoSQL databases with the native query complexity supported by RDBMS systems. Read on for more details on clustering.

    How does TimescaleDB scale?

    TimescaleDB’s architecture leverages two key properties of time-series data:

    • Workloads have a natural partitioning across both time and space.

    Our documentation describes these design elements in more depth.

    How should I configure chunking?

    See the Best Practices section of our documentation.

    How are hypertable chunks determined across the space dimension?

    All hypertable chunks are partitioned automatically across time, which is necessary for right-sizing the chunks such that the B-trees for a table’s indexes can reside in memory during inserts to avoid thrashing that would otherwise occur while modifying arbitrary locations in those trees. In addition, the user has the option when creating the hypertable to partition across the space dimension (partition key) on something like a device id, customer id, or other unique id. Space partitions use hashing: Every distinct item is hashed to one of N buckets. The main purpose of space partitioning is to enable parallel I/O to the same time interval or to build smaller tables when regularly performing a range query for a single device/customer/ticker. For more details on space partitioning, see Best Practices.

    How do I update an existing installation?

    See our .