Timescale raises $110M Series C
timescale.com
timescale.com
I just want to say that we wouldn't be here without the support, feedback -- and yes, even the honest critiques -- from the HN community. So thank you everyone.
As we like to say, we've come a long way in the past 5 years, but we're just getting started :-)
And we're hiring globally for our remote-first team!
https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D...
It looks like there has only really been 7-10 full time contributors and for you to have raised what you have with such a small team is quite impressive. Is development happening elsewhere or is my hunch correct?
Edit: Thanks to feedback from mfreed, below is a more accurate picture of development activity:
https://oss.gitsense.com/insights/github?p=authors&q=pull-ag...
The core timescaledb repo [0] currently has 10-15 primary engineers, with a few others working on DB hyperfunctions and our function pipelining [1] in a separate extension [2]. I think generally the set of outside folks who contribute to low-level database internals in C is just smaller than other type of projects.
We also have our promscale product [3], which is our observability backend powered by SQL & TimescaleDB.
And then there is Timescale Cloud [4], which is obviously a large engineering effort, most of which does not happen in public repos.
Interested? We're growing the teams aggressively! Fully remote & global.
https://www.timescale.com/careers
--
[0] https://github.com/timescale/timescaledb
[1] https://www.timescale.com/blog/function-pipelines-building-f...
[2] https://github.com/timescale/timescaledb-toolkit
[3] https://github.com/timescale/promscale ; https://github.com/timescale/tobs
[4] https://www.timescale.com/blog/announcing-the-new-timescale-...
I've dealt with databases for a very long time, But I frankly find SQL extremely hard and I could never imagine forking postgres to improve it.
Is this your first company, did you personally write much of the early code, or did you hire a team to do so.
As a side note, I'm seeing an insane amount of movement when it comes to business to business VC funding.
What about an entertainment product ?
Hypothetically, if you were given a year off to come up with a new product, do you think it would be possible?
I would absolutely love to read a blog post where you discuss the challenges you've faced getting here.
[0]: https://www.timescale.com/blog/when-boring-is-awesome-buildi... [1]: https://www.timescale.com/blog/40-million-to-help-developers...
I plan on reading this all in full.
Edit : Very impressive way to pivot , best of luck !
There's a lot of lessons I've learned along the way
These are probably two of the top ones:
1. Solve a big problem that people have (even better if you personally have it)
2. Who you work with matters more than what you work on :-)
Looks like you had a small company, that was able to pivot and expand.
I'm planning on spending at least 3 months diving into my side projects, and then I'll try YC again.
Do I then just cold email various YC like funds until I fetch some interest, or should I focus on building my project.
I realize Timescale and Mongo are very different things, but when I got professionally started with software 10 years ago, the MongoDB courses (and the stanford online Intro to DB course) were immensely helpful. Working with Timescale professionally now I'm often unsure whether I'm doing things suboptimally, e.g. making tables hypertables when a regular table might be better, flexibility and capabilities of indexes with hypertables, and application-facing tooling.
[1]: https://www.youtube.com/watch?v=tLJm2oStD9w [2]: timescaledb.slack.com [3]: https://www.timescale.com/forum/
We agree that the world needs more PostgreSQL and TimescaleDB educational content, and welcome any help!
https://www.timescale.com/blog/how-trading-strategy-built-a-...
I agree completely with this. The documentation is great and the community on slack has been incredibly helpful when I've posted there. Even still, I personally think a lot of people would benefit from course content like MongoDB provides.
In one occurrence we wanted to create a VPC peering between the a database hosted on Timescale Cloud and our Kubernetes cluster hosted on Azure. For this you need to put the Azure resource group name in a form on Timescale cloud.
Turns out our resource group name contained an uppercase character and the form on Timescale Cloud has a (broken) validation that required the name to be all lowercase. We couldn't easily change that name since that would have required us to re-create our production AKS/K8S cluster.
After contacting Timescale support (as a paying customer) the answer was basically: "Well, we require the resource group name to be lowercase, we can't change that, sucks to be you, bye"
We can live without that VPC peering, so we didn't push that further, but there are zero technical reasons for that restrictions and I would bet that its just a broken validation regex in their backend that they are unwilling to fix.
It's true that on Azure we require both the resource group name and also the Virtual Network name to be in lowercase.
But Microsoft names are case-agnostic, so this should be okay.
We've had other customers with this issue before and converting the resource group name to be lowercase worked for them.
Also, sometimes technical restrictions exist for internal reasons that are not obvious / hard to share externally. :-)
That said, I shared your message internally and someone is looking into this. Stay tuned. More soon.
Again, I want to emphasize that I find it really great that you took the time to answer here.
To be fair, I don't have a good answer on why the input box does require the resource group name to be lowercase, but I ran through the steps end-to-end, and as akulkarni said, the names are case agnostic on the Azure side, so you'd just need to input the resource group name lower case to create it successfully.
Sincerely, thank you for the feedback, as this is how we learn and improve. If you give this a shot and run into any trouble, please do let us know, and we'd be happy to help troubleshoot.
Does Timescale contribute back to PostgreSQL or do they truly only build on top of it? https://www.postgresql.org/community/contributors/ only lists two contributors and they both worked on Postgres before joining Timescale.
Not reinventing but reimplementing it for Postgres, which didn't have serious OLAP capabilities before. Lots of "newsql" systems are combining OLTP and OLAP by starting at one side and adding the other.
So far Timescale has column-oriented compressed storage and scale-out partitioning, and they're working on matching the compute part.
[1]: https://www.timescale.com/blog/what-is-clickhouse-how-does-i... [2]: https://www.pradeepchhetri.xyz/clickhousevstimescaledb/ [3]: https://tech.marksblogg.com/benchmarks.html
NoSQL databases with their half assed SQL grammar implementations are a real pain to use in real applications where they often have to be handled differently in code vs the RDBMS because either their syntax is slightly different or their connection stack is incompatible.
closest I can find are these:
Let me know if you want help in putting together a draft, I'm good at finding sources[0] to establish notability.
[0] https://www.google.com/search?tbs=bks:1&q="TimescaleDB"+-wik...
same username on WP.
Moved draft into article namespace.
This isn't my first rodeo. We'll see how it goes.
That is, "I have this seldomly-updated list of ~10000 things, and I'm going to need to join it against my time-series data."
With other time-series databases I've dealt with, it's an afterthought at best and the answer is typically "Enrich the data via flink/benthos/etc. on import and avoid using any kind of join."
Does Timescale's use of PostgreSQL circumvent this issue, both in terms of storage of lookup tables, and performance on join?
There are other common queries related to what you describe, like a "last point query": Tell me the last record for each distinct object. Here, for example, we've built special query optimizations to significantly accelerate such queries:
https://www.timescale.com/blog/how-we-made-distinct-queries-...
How are you dealing with backups/WAL and general DB administration? Are you using Timescale Cloud?
I've also had many discussions on backups (Barman, backrest, Wal-E/G) etc and always feel like I have to look it up afresh every time to get myself back up to speed on which one I should be using.
we use 1500IOPS just to speed up our read-only jobs and reports.
i'm just using AWS EBS snapshot feature ( every hour ) for backup.
In the I’ve had terrible experiences with on-demand IOPS but now I feel like even 1000 provisioned (the least you can get) is too much for the workload I was running… the app was mostly idle but had bursts that would overwhelm
The pricing seemed more of an all or nothing investment and didn't make sense if we weren't ready to start using the extra functionality just yet. Was hoping that it would be similar to Cloud SQL and just cost extra depending on usage.
System performance scales well with latest SSD HW.
As compare to cloud base approach that is limited by network/cloud speed.
One can store logs per day / week / year in separate db files as needed.
Backup of small db files for last few days/weeks are trivial with rsync.
In any case, does anybody know what are the advantages of one over the other? Big thanks!
https://www.timescale.com/blog/timescaledb-vs-amazon-timestr...
- https://github.com/timescale/tsbs
- https://github.com/timescale/tsbs/blob/master/docs/timestrea...
Disclaimer: I am highly biased, as I am funding/researching/developing a DBMS myself. Out of necessity though, as we constantly hit bottlenecks in the persistent I/O layer. We are not selling or offering anything, but will soon share some fresh internal results on aforementioned topics.
In the meantime, here is a list of startups re-implementing mostly identical ideas: https://unum.cloud/post/2021-12-31-dbms-startups/
https://github.com/orioledb/orioledb/blob/main/orioledb-post...
On a side note, nice interesting brief comments & shares elsewhere on this site. :thumbup:
The web page just drops as many buzzwords as possible - web3, crypto, nfts, monitor soil to fight global warming - it looks like a disaster to anyone who understands the basics of programming.
The problem something like timescale tries to solve is dealing with "high cardinality." When you have many unique values the indexing approaches needed to ensure performance start becoming different. You'll run into write performance issues if need indexes on every single column, and every single combination of columns, and each column has a large number of unique values. While the common factor many of these datasets tend to share is that they are being constantly generated by some kind of sensor/probe/live-system, they tend to have a variety of other dimensions that are also high-cardinality.
Values over time like audio is a one dimensional signal. Seeking is basic data structure stuff, filtering is basic signal stuff. There aren't going to be other dimensions like time, which makes the other values just other channels. If you need to combine dense values they can be not only filtered, but filtered into individual distributions.
People give abstract descriptions like you have here, but I'm just not seeing a difficult problem in all of this.
Boy were you right about that
And you dismissed it as still not being difficult.
The Timescale folks did all the hard work of finding product / market fit for you. If this problem is so trivial, you'd make a faster, cheaper, more reliable product and steal their lunch. Not only their lunch but Clickhouse, AWS Timestream, etc..
The number that stood out the most was 700 million values per second, which is about 11.6 million per second. This is still less than the data in a single 4k image. My guess is that none of this is a feat of engineering, but that it's just enough work that many people that need it won't create their own solution.
It does a good job laying out why TSDBs are used and some of the tricks they leverage to store this type of data. See the requirements for the service layed out in the paper:
• 2 billion unique time series identified by a string key.
• 700 million data points (time stamp and value) added per minute.
• Store data for 26 hours.
• More than 40,000 queries per second at peak.
• Reads succeed in under one millisecond.
• Support time series with 15 second granularity (4 points per minute per time series).
• Two in-memory, not co-located replicas (for disaster recovery capacity).
• Always serve reads even when a single server crashes.
• Ability to quickly scan over all in memory data.
• Support at least 2x growth per year
Lots of organizations want to adopt an SRE/devops model and want a similar system. Also one thing you should know is that trying to accomplish this with traditional DBMS is usually possible but since it is not making specifically optimized trade offs it usually is more expensive and requires a lot of tuning/expertise.
Lots of organizations (even legacy companies) have a massive need for this kind of service. Also there are very cheap options out there than can handle the million metric use case for basically a <100$ a month is infra costs. The use case is definitely there and even if it's possible with traditional DBMS systems, it usually cheaper and more performant to use a dedicated TSDB.
The latter group is designed to analyze lots of data (calculating aggregations across billions of rows) and have developed features like storing data as columns, using compression, batch/vectorized processing, scaling out across multiple servers, and other techniques to get that performance. Timescale is an extension to Postgres that brings these capabilities to Postgres and is one of a very few relational databases that offer OLTP+OLAP in a single product.
The time-series niche is what they targeted first, and the product offers lots of useful features around time-related data, but it's also a generic analytical database offering at this point.