Announcing TimescaleDB 1.0: The first enterprise-ready time-series database to support full SQL and scale
By Ajay Kulkarni
17 - 22 minutes
Over 1M downloads; production deployments at Comcast, Bloomberg, Cray, and more; native Grafana integration; first-class Prometheus support; and dozens of new features signify positive momentum for TimescaleDB and the future of the time-series market
If you work in the software industry, you already know that 1.0 announcements generally signify that your product is “production-ready.”
Ironically, just last week we got this question on Twitter from a TimescaleDB user, who founded a weather mapping company:
Yes, our 1.0 release is a little overdue as we’ve actually been production-ready for quite some time now.
Today, just a year and a half after our launch in April 2017, businesses large and small all over the world trust TimescaleDB for powering mission-critical applications including industrial data analysis, complex monitoring systems, operational data warehousing, financial risk management, geospatial asset tracking, and more.
“At Bloomberg, we have millions of data feeds and trillions of data points dating back over 100 years. My team and I have been extremely pleased with TimescaleDB’s capability to accommodate our workload while simplifying geo-financial analytics and data visualization. If you are looking to support large scale time-series datasets, then TimescaleDB is a good fit.”
— Erik Anderson, Lead Software Engineer at Bloomberg
Since our launch, we’ve experienced some significant momentum:
Surpassed 1 million downloads and 5,000 GitHub stars
Is fast, flexible, and built to scale: ingests millions of data points per second; scales tables to 100s of billions of rows and 10s of terabytes; returns quick responses to complex queries; much faster than InfluxDB, Cassandra, MongoDB, and vanilla PostgreSQL for time-series data (more benchmarks below).
Supports full SQL: looks like PostgreSQL on the outside, architected for time-series on the inside.
Offers the largest ecosystem of any time-series database including: Tableau, Grafana, Apache Kafka, Apache Spark, Prometheus, Zabbix support.
Is proven and enterprise ready: offers the reliability and tooling of PostgreSQL, enterprise-grade security, production-ready SLAs and support.
Is designed to manage time-series data: automatic space-time partitioning, the hypertable abstraction layer, adaptive chunk sizing, new functions for easier time-series analytics in SQL, and more.
Includes other features: geospatial analysis, JSON support, and easy schema management.
If you’re ready to get started, please download TimescaleDB directly from the installation guide. If you’d like to explore the first release candidate for TimescaleDB 1.0, you can install it via Github or Docker.
Once you’re ready for production and are looking for deployment assistance and production-level SLAs, we also offer enterprise support.
If you have time-series data and are looking for a performant, easy-to-use, SQL-centric, and enterprise-ready database, and would like to learn more, then please read on.
We started this journey with the realization that there was a need for a time-series database that could scale and support SQL.
The response from the developer community from the start was very encouraging. In fact, just one month after our initial launch, we learned that TimescaleDB was deployed at the operator-facing dashboards in 47 power plants across Europe and Latin America. Four months later, we learned TimescaleDB was merged into the mainline product of Cray’s supercomputing distribution for monitoring workloads.
Fast forward to today and the feedback and adoption continues to be very strong. There’s a clear need for our database in the market.
“Our SmartCast Link appliance uses TimescaleDB to collect sensor readings from IoT-enabled lighting products. From our experience, TimescaleDB is uniquely positioned in the time-series database market as the only serious player that scales while natively supporting a robust, proven SQL engine. Also, Timescale’s dedication to support may be the best I’ve seen from an open source project.”
During this age of digital transformation, TimescaleDB challenges the assumption that technologies built-from-scratch are always better. Instead of developing an entirely new database from the ground up, our engineers chose to build on top of PostgreSQL, a reliable 20+ year old database with a powerful extension framework.
That decision paid dividends immediately. Instead of having to wait the 5–10 years that it typically takes for a new database to become “production-ready”, TimescaleDB has been ready for production workloads right from the start, and from launch has been able to offer the largest ecosystem of tools and connectors of any time-series database.
However, we continue to battle skepticism that a database built as an extension to PostgreSQL, or that any database that supports SQL, can work for time-series analysis.
Some even claim that the relational model is not scalable. However, if architected with time-series workloads firmly in mind, this is simply not true: relational databases can indeed scale very well for time-series data.
Leveraging the power of a relational database with SQL at scale becomes quite powerful. Not only can you ask deeper questions about your time-series data, but you can enrich it with other business data or metadata for deeper insights. TimescaleDB users at Comcast have found such success by enriching their DevOps data for key business questions:
“Initially my colleagues were skeptical when I suggested storing metrics for our 120 petabyte data center in a relational database, but after replacing the prior NoSQL database with TimescaleDB we couldn’t be more happy with the performance. Because TimescaleDB is an extension of PostgreSQL, we’re starting to expand the scope of the metrics storage to power executive dashboards and advanced analytical functions that our prior NoSQL solution couldn’t support.”
— Chris Holcombe, Production Dev Engineer at Comcast
Thanks to time-series being the fastest growing category of databases over the past 2 years, there are several options today to store your time-series data. As a result, picking the right database is becoming more important than ever.
As part of our development process, we’ve run performance benchmarks to see how TimescaleDB stacks up versus some of the leading alternatives: PostgreSQL, Cassandra, MongoDB, and InfluxDB. The results were very promising and solidified our confidence that TimescaleDB is enterprise-ready:
TimescaleDB is built with the reliability and features of a traditional relational database, but also scales in ways previously reserved for NoSQL databases.
We’ve achieved this by developing specialized features including automatic space-time partitioning, the hypertable abstraction layer, adaptive chunk sizing, new functions for easier time-series analytics in SQL, and more. We’ve done this while retaining all the wonderful features one would expect from PostgreSQL: a variety of data and index types, secondary indexes, easy schema management, geospatial support (via PostGIS), JSON support, and more.
TimescaleDB’s features, flexibility, and commitment to our users has proven extremely valuable.
“In less than a year TimescaleDB has completely eliminated the need for us to maintain our own database scaling logic. With deep hooks into the query planner it is also accelerating our real-world analytic queries without any additional effort allowing us to answer more questions faster than ever. Most importantly, it has done all of this while still maintaining the reliability and full SQL interface we have come to expect from PostgreSQL.”
Over the past few months we’ve been laying the foundation for our 1.0 announcement by releasing several new updates.
Here are some key takeaways from recent releases. Each of these releases signify that TimescaleDB is more performant at scale, provides a user-friendly experience, and ultimately makes time-series analysis and data management easier.
Scheduler framework: This release introduces a background job framework and scheduler. Future releases will leverage this scheduler framework for more automated management of data retention, archiving, analytics, and the like.
Telemetry: Using this new scheduler framework, TimescaleDB databases now send anonymized usage information to a telemetry server via HTTPS, as well as perform version checking to notify users if a newer version is available. For transparency, a new get_telemetry_report function details the exact JSON that is sent, and users may also opt out of this telemetry and version check.
Adaptive chunking: This feature allows the database to automatically adapt a chunk’s time interval, so that users do not need to manually set (and possibly manually change) this interval size. This type of automation can simplify initial database testing and operations.
15x faster planning times: Planning time improvement when a hypertable has many chunks by only expanding (and taking locks on) chunks that will actually be used in a query, rather than on all chunks (as was the default PostgreSQL behavior). Allows TimescaleDB to efficiently handle 10,000s of chunks in a single hypertable.
Multi-extension support: Support for multiple extension versions on different databases in the same PostgreSQL instance. This allows different databases to be updated independently and provides for smoother updates between versions (with upgrades no longer requiring a database restart).
We also developed the graphical SQL query builder for Grafana, as well as some TimescaleDB specific support, slated for inclusion in their upcoming 5.3 release:
We also added native support for TimescaleDB to serve as a remote storage backend for Prometheus. This adds many benefits to Prometheus: a full SQL interface, long-term replicated storage, support for late data and data updates, and the ability to JOIN monitoring data against other business data.
Based on the adoption and wide breadth of use cases we are seeing, one thing is becoming clear to us: all data is essentially time-series data. To some of our users, this insight is already obvious:
“Effectively we model (or are moving to model, at my behest) all of our data as events. If someone signs a loan, that happened at a particular time. If the status of a loan changes, that happened at a particular time. It is important to me from a design standpoint to have an auditable/queryable history as well as data immutability for operational advantages. Basically anything that isn’t time series, I’m wanting to coerce into a time series (or event based) model.”
— Devin Ekins, a Platform Engineer at Earnest (a Navient Corporation company)
We are building TimescaleDB to accommodate this growing need for a performant, easy-to-use, SQL-centric, and enterprise-ready time-series database. The technology that solves this problem will become a foundational component for businesses worldwide. And with our momentum so far, TimescaleDB is poised to be this foundational technology.
We are excited for what the future holds for TimescaleDB. We’ve made some big strides in just 18 months, with even bigger things to come.