Year of the Tiger: 12 (and Then Some) Timescale Highlights of 2022

Twenty twenty-two. What a year, huh?

As the old year comes to an end and a new year approaches, it’s time to look back at all that we accomplished in 2022 and start setting goals and making wishes for 2023.

Every holiday season, we resume the Timescale tradition of sharing our achievements and favorite content pieces to celebrate #12DaysofTimescale—the kind of retrospective all developers can get behind.

This year, though, we’re adding a little twist. Keep reading for a recap of our major launches (with helpful links for your time-series work), team achievements, and the highlights of the year—including bits from an infamous, mic-dropping retrospective by our CTO and my fellow co-founder, Mike Freedman.

Join us as we remember this fun ride!

We Closed Our Series C 🦄 Funding Round

Well, 2022 was the Year of the Tiger 🐯, and who are we to deny it? We serendipitously kicked off 2022 with the announcement that we had raised $110 million in our Series C, led by Tiger Global (seriously, we still don’t believe in coincidences).

With the funding, Timescale’s valuation surpassed $1 billion. Combined with previous rounds (2018, 2019, 2021), we raised more than $180 million to drive growth and enable developers to build the next wave of computing. And with great power comes great responsibility, so not only are we empowering developers, we have created lots of software and new features to make their jobs easier.

We’re also pretty good at celebrating our accomplishments. Case in point? Just check out our social media marketing manager, Jill Proman, celebrating the news of our Series C in Times Square, New York.

We Launched Some Cool Database Features 🚀

TimescaleDB 2.6: Introducing compression for continuous aggregates

We believe our mission is to help developers, first and foremost.

So, when we heard users requesting compression for their continuous aggregates, we couldn’t say no. Continuous aggregates, our improved version of PostgreSQL materialized views, already allowed developers to downsample their time-series data considerably since they could keep their continuous aggregates even when the original raw data had been dropped from the underlying hypertable.

But guess what? Timescale users are handling huge volumes of time-series data—our community wanted to use compression over their continuous aggregates to save even more disk space. This functionality was introduced in TimescaleDB 2.6, allowing users to combine continuous aggregates, compression, and data retention policies to save up to +95 % in storage.

TimescaleDB 2.7: Making data aggregation faster and better

By popular demand, continuous aggregates were also the protagonists of TimescaleDB 2.7. It’s no surprise that they’re among Timescale’s most popular features—continuous aggregates are aimed at solving one of the most difficult challenges for developers and data scientists working with time-series data: aggregating it efficiently without having to query billions or trillions of raw data rows.

If with Timescale 2.6 we helped users compress their continuous aggregates to achieve incredible savings, in Timescale 2.7, we introduced a completely redesigned materialization process that made them better and faster, dramatically boosting performance.

First, continuous aggregates became blazing-fast—and by blazing-fast, we mean up to 44,000x faster in some queries than previous versions. Second, they became smaller: in TimescaleDB 2.7, continuous aggregates needed 60% less storage on average (which directly translates into more cost savings!). Lastly, we also removed limitations around continuous aggregates, like the possibility of using DISTINCT, FILTER, or ORDER BY.

But that’s not all we did with Timescale 2.7. Once again, we decided to cater to our community by solving an issue that often popped up in our Community Slack, Support, and Forum (the latter is also a 2022 highlight, but we’ll get there).

The problem revolved around the high planning time in the presence of many chunks (data partitions within a database table) in queries using the now () function, which had been haunting us in partitioned vanilla PostgreSQL too. (Hey, needless to say, we’re heavy PostgreSQL users and fans!)

Long story short, not only did we optimize the function, but we made it scale with the number of chunks in hypertables. So, the more data partitions you’re dealing with, the more you’ll notice the speed improvement—up to 401x faster for 20,000 chunks compared to the previous version.

Not bad for the first six months of the year. 🐯

TimescaleDB 2.8: Time zones in time_bucket

When we inquired our team about their 2022 highlights, developer advocate Chris Engelbert was the first to jump up and reply: the updates to the time_bucket hyperfunction that we shipped with TimescaleDB 2.8!

time_bucket has always been a superstar among the Timescale features. It allows developers to easily group their time series by arbitrary buckets of time, for example, by day or week (like an improved version of PostgreSQL’s date_trunc). But before TimescaleDB 2.8, there was some highly-requested functionality missing in time_bucket: the possibility of bucketing by month and year and specifying time zones in the interval definitions.

Before becoming a Timescale developer advocate, Chris was a Timescale user in his own startup and had nightmares about manually defining his customers’ time zone on his views. It’s no wonder he was over the moon with TimescaleDB 2.8, which introduced this out-of-the-box for time_bucket, enabling super time-based queries and reporting by supporting bucketing by month, year, and time zone.

TimescaleDB 2.9: Continuous aggregates on continuous aggregates

We already mentioned that continuous aggregates are one of our most popular features, so why not have continuous aggregates on top of other continuous aggregates?

For our final TimescaleDB release of the year (which will be available in Timescale and Managed Service for TimescaleDB in January 2023), we wanted to give users the possibility of creating continuous aggregate hierarchies.

Each continuous aggregate is defined on top of the previous one, providing a lower granularity view of the same dataset but making the refresh process for higher-level continuous aggregates lightning-fast.⚡This also enables the developer to define more diverse sets of continuous aggregates without significant additional costs.

For example, a continuous aggregate that provides a daily summary only needs to go through 24 records when built on top of a continuous aggregate that provides an hourly summary—forget those tens of thousands of records stored in the raw hypertable for that day.

We also continued to improve the time_bucket_gapfill function to allow specifying the timezone to bucket, and introduced fixed schedules for background jobs, the ability to check job errors, and the option of configuring the availability of the data node, among other noteworthy features.

We Reduced Downtime for our End Users With One-Click Replicas 👯

Mike and I are constantly bouncing ideas off each other. Oh! Mike is our co-founder and CTO.

For the most part, we're always thinking about how to make our customers' lives easier. This formed a huge piece of 2022—simplifying operational database management for our customers.

If you’re working with production databases, a big part of this peace of mind is knowing that your end users won’t experience any significant downtime in case anything happens to your database—and that you won’t be called in the middle of the night to put things up again. This is where high availability replicas come in, a feature we launched earlier this year in Timescale.

Database replication in Timescale is as easy as pressing a button. If your database fails, your connections will be automatically switched to the replica, and your end users will only experience a few seconds of downtime. But replicas in Timescale are not only useful for high availability: they can also improve your performance, as they also act as read replicas—you can direct your heavy read queries to the replica, freeing up resources in your main database for writes.

If you want to learn more about how this works under the hood, read this blog post to learn how high availability works in Timescale.

We Allowed Developers to Do Faster and Safer Testing With One-Click Forking

Forking is another way we made our customers’ workflows easier in Timescale. Again, we made it effortless: with a click of a button, you can spin up forks, identical copies of your database but—and this is a very convenient “but”—with different resource configurations.

You can use forks to quickly spin up databases with production data on them, deleting them also with a click of a button once you’re done with them (and you’ll only be charged for the time the fork has been running).

This feature can make your life easier in so many ways:

• You can use forks to run tests in up-to-date production data.
• You can use forks to create and refresh staging environments.
• You can use forks to test upgrades.
• You can use forks to provide access to production data but not to the production databases and much more.

“You can spin up another service for another team member for testing and actually spin up a different size,” summarized Mike at our latest All Hands, stressing the flexibility and time savings the feature brings development teams.

Thanks to You, We Learned More About the PostgreSQL Community With the 2022 State of PostgreSQL Survey

After a pandemic hiatus in 2020, our State of PostgreSQL survey was back for its third edition, advancing our desire to provide greater insights into the vibrant and growing PostgreSQL user base.

In 2022, nearly one thousand developers answered the survey, more than double compared of the previous year. Download the full report to learn more about this amazing community, or read this blog post if you want to know what PostgreSQL committer and developer, Heikki Linnakangas, had to say about the survey results as we celebrated PostgreSQL’s 25th birthday!

We Have Grown the Timescale Team (and Met in Person!)

Without growing our team, we couldn’t make database developers’ lives easier and release new features to allow them to build the next wave of computing. Such ambitious goals require efficiency and constraint but also the right talent to solve complex problems.

The past 12 months have been huge for the Timescale Team: in 2022, we nearly doubled in size, hiring one hundred new Timescalers, half of which for the Engineering and Product teams. No wonder recruiting manager Shauna Lassche considers it one of 2022’s highlights: “We hired some awesome people who are making an impact on our product.”

For those on the other end of the recruiting spectrum, joining a global and diverse company with a fun-loving culture was also a highlight. At least that’s what senior product manager Jim Meehan promptly replied in our highlight Slack appeal, having just joined just a few weeks ago: “It’s so exciting to be part of an employee-first company. It’s my first week, and I’ve been wowed by the onboarding experience and overall company culture.”

Alaap Murali, another senior product manager who responded to our Slack call, said: “I’m so grateful to work with so many wonderful and talented people!” So if you want to join our fully remote, global, and diverse team, check out our careers page and help us build the next great database company.

But even more significant than working remotely together, one of the most wonderful things of 2022 was the team’s numerous face-to-face meetings, whether at Timescale offsites, spontaneous team gatherings, or events, such as AWS Re:Invent. It always warms our hearts when Timescalers finally meet in person, and this year we could finally catch up following the quiet pandemic years.

We Did Some Benchmarking, Not Benchmarketing

When you live and breathe data, making informed data-driven decisions matters. This is why we love benchmarking our products against others, backing up our claims with rigorous numbers and facts. There is a line we always say at Timescale: we do benchmarks, not benchmarketing.

In September, we showed how TimescaleDB expands PostgreSQL for time series and analytics by improving query performance by up to 1,000x or more, reducing storage by 90 %, and providing additional crucial features for time-series applications and analytics.

A few months later, in November, we answered why so many developers are migrating from Amazon RDS for PostgreSQL to Timescale: in our head-to-head challenge, Timescale delivered up to 350x faster queries, a speedier ingest by 44 %, and storage savings of up to 95 % for time-series data.

We Turned Promscale Into a Full Observability Backend

This year, the Promscale Team has made incredible progress in developing a scalable metric and trace observability backend for Prometheus, Jaeger, and OpenTelemetry.

The main idea behind Promscale is, again, to simplify developer workflows (so they can focus on what really matters) by offering observability powered by SQL. With PostgreSQL and TimescaleDB, we provide you with a robust and scalable database for time-series data. But what about using all the data from your complex distributed systems and cloud-native architectures to monitor their performance and prevent dysfunctional behavior?

By giving developers support for tracing and alerts and allowing them to add and store their OpenTelemetry data, Promscale bridges that gap. Devs can now understand how their systems’ components work and interact with each other in real-time.

Then, in October, Promscale became one of the only two external certified storage backends for Jaeger, a popular tool for distributed tracing (if you want to learn more about this, check out this blog post we recently wrote).

In addition to passing all the Jaeger storage certification tests, Promscale ensures a rich query experience with SQL since it’s built on PostgreSQL and TimescaleDB. Gaining in-depth insights into your systems was never this easy—and that is definitely something to celebrate.

We Had (Literally) an Eventful Year

While we love meeting each other, another huge highlight of 2022 was getting ourselves out there and meeting many of you face-to-face at conferences and meetups. Thank you so much to all of you who dropped by our booths!

This year, we attended or sponsored 43 events (that’s almost four events per month), from PostgreSQL conferences on both sides of the Atlantic (PG Conf NYC and PostgreSQL Conference Europe) to the massive AWS Re: Invent, in Las Vegas, in November.

Showing our demos in person, listening to your feedback, and finding ways to solve your use cases was undoubtedly one of the year's highlights.

We Launched Early Access Tiered Storage for Timescale

Barely a month ago, we announced a very exciting private beta: we’re building a multi-tiered storage architecture in Timescale engineered to enable infinite, low-cost scalability for your time series and analytical databases in the Timescale platform.

This is what happens when you insert data into a Timescale time-series database with our new multi-tiered storage backend:

1. Your most recent data will be written into a high-performance storage tier optimized for fast queries and high ingests.
2. Once you don’t access that data frequently, you can automatically tier it to a lower-cost object storage tier by setting up a tiering policy. The data in the low-cost storage tier remains fully queryable within your database, and there’s no limit to the amount of data you can store—up to hundreds of TBs or more. Our low-cost storage tier has a flat price for data of $0.021 per GB/month—cheaper than Amazon S3.

We’re inspired by our vision to build a data infrastructure that extends beyond the boundaries of a traditional database, combining the flexibility of a serverless platform with all the performance, stability, and transparency of PostgreSQL that developers know and love.

We Built a Better Developer Experience With Timescale 2.0

It took us about a year to complete and involved a massive company-wide effort between designers, engineers, and product designers who spent a lot of time planning, building, and iterating the new user interface of our cloud-native database platform. But it was all worth it.

We presented Timescale 2.0 earlier this year, in December, and it is one of 2022’s biggest wins, both for the team who laboriously redesigned it but also for every Timescale developer who now enjoys a seamless developer experience.

I highly recommend checking out the blog post the team wrote about this redesign journey and browsing their interactive prototype of the UI library.

All Thanks to You!

Yes, you (reading this)! Whether this is your first engagement with us or you’ve been here through the year, you’re a highlight in our story. As mentioned, Timescale is a help-first company: our goal is to help developers solve problems, help move the industry forward technically, and make it more welcoming and diverse to all. We want to enable developers to build the next wave of computing, and we couldn’t do it without you and your feedback.

This is why we’re constantly focused on maintaining and opening new communication channels with our users, such as our Slack Community (with nearly 10,000 users!) and the Timescale Forum, which we kicked off in January, right at the start of 2022.

And Then Some

If this sounds like a lot, brace yourself—there is more to come. We weren’t kidding when we said that 2022 was a huge year for us. In this Year of Tiger, our Engineering Team also reinforced our Kubernetes infrastructure for Timescale.

Timescale runs in Kubernetes, and this year, we introduced a custom runtime mode for Patroni, ensuring that our customers’ TimescaleDB clusters will not be negatively impacted by etcd failures. Due to this work, instances on Timescale can continue operating safely and smoothly even in adverse runtime networking conditions.

We also introduced a new methodology for installing extension updates without downtime and built tools for detecting and mitigating out-of-memory (OOM) errors before they cause trouble. This made Timescale a highly resilient platform, with zero system-wide outages almost every month.

And finally, let’s round this blog post off with a few more numbers (because we ♥️ data):

• # of GitHub issues closed: 367 issues
• # of TimescaleDB instances created: more than 36 million TimescaleDB instances created over the last 365 days (we’re aware this figure does not reflect actual usage, as some were dropped, but still!)
• # of releases: 9 releases this year (including patches) for TimescaleDB, 10 releases and patches for Promscale, and 9 main releases and patches for Timescale (these are just the main ones because trust us, we had smaller releases practically every day) 🎉
• # of PostgreSQL commits: 18 authored, 19 reviewed, and 5 reported
  

After completing all this work for our fantastic community, we’re looking forward to the holiday season for some well-deserved rest and time with our family and friends. But we could not be prouder of what we achieved in 2022, and we are honored to share it with you.

We wish you a happy, healthy, and hopeful holiday season! Here’s to an even better 2023! 🎉