Thanks for the recommendation! And glad to hear TimescaleDB meets your needs. I wanted to add some color to hosting / deployment options around TimescaleDB.
Options are as follows:
[1] Fully-Managed TimescaleDB Enterprise on Timescale Cloud
TimescaleDB Open Source hosted on Public Clouds:
[2] Azure PostgreSQL
[3] DO Managed-Postgres (mentioned above)
[4] Alibaba Cloud
Not hosted, but managed service options:
[5] ClusterControl from our friends at Severalnines
One point of clarification for readers of @neslinesli93's post is that Timescale does not create "heavy" indexes.
We do create some default indexes that PostgreSQL does not, but these defaults can be turned off. We also allow you to create indexes after bulk loading data, if you want to compare apples-to-apples.
But to be clear, the indexes Timescale creates are the same, or can often times be cheaper, than PostgreSQL (remember, TimescaleDB is implemented as a PostgreSQL extension). We're always happy to help people work through proper set up and any implementation details in our Slack community (slack.timescale.com).
Timescale | New York, NY | Stockholm, Sweden | ONSITE preferred, REMOTE considered | FULL-TIME
Time-series data is everywhere, and the powerful time-series database we are developing (TimescaleDB) is a key building block across a range of industries: IoT, DevOps, monitoring, eventing, finance, industrial, logistics, transportation, and via the edge, on premise, and cloud deployments. It powers users' core products and services.
We need extraordinary engineers, marketing and customer success professionals to join our team in NYC and Stockholm.
Hi, the link you posted seems broken. Also just wanted to clarify that TimescaleDB is in fact a relational database, being built as a PostgreSQL extension. Looking at the nature of time-series workloads (namely appending data about recent events) we can architect the database differently for time-series workloads and applications powered by time-series data; scaling insert rates and storage capacity, increasing query performance and simplifying operations, while retaining full-SQL and the reliability of Postgres.
Yes, they have. kdb+ has been the standard bearer within finance for more real-time trading applications. Still, q as a query language tends to marginalize more of the organization from having access to the data.
TimescaleDB offers full-SQL at scale, opening the database up to more people. It's used to power longer-term trading platforms (for e.g., commodities trading) and interactive analytical dashboards (for e.g., research analysts). We also see applications in compliance and risk management.
And yes, TimescaleDB is open-source. So we see TimescaleDB as complementary to kdb+, which has been around for much longer as a proprietary system, is certainly full-featured and powerful, but is used more in real-time trading applications.
Thanks for asking. For some of the larger companies, takes a little bit of time to work with their marketing / legal teams :)
We do list some of them within the blog post:
- STE Energy, to back operational dashboards used to monitor 47 power plants in Italy, Albania, Colombia, Perú, Honduras, Costa Rica, and Chile, replacing Redis
- InTraffic, which monitors all of the roughly 5,000 remote controllable railroad switches of the Dutch railways, for use with Tableau as a Business Intelligence solution
- One of the largest American telecom companies, for storing server health data
- A top financial services firm, to replace Oracle for powering interactive analytics of market data
- A public lighting and semiconductor company, for deployment in a small-footprint IoT edge device collecting and analyzing sensor readings
Hi, thanks for the feedback on our FAQ. We did write a blog post that goes into what time-series data is and why purpose-built time-series databases should exist / are necessary.
Timescale | New York, NY | Stockholm, Sweden | ONSITE | FULL-TIME
Time-series data is everywhere, and the powerful time-series database we are developing (TimescaleDB) is a key building block across a range of industries: IoT, DevOps, monitoring, eventing, finance, industrial, logistics, transportation, and via the edge, on premise, and cloud deployments. It powers users' core products and services.
We need extraordinary engineers and customer success professionals to join our team in NYC and Stockholm.
Here are some more details on our future plans for clustering. We do have horizontal scale-out clustering on our roadmap and it's hard to say exactly when it will be released, but we are aiming for the 2nd half of 2018.
That said, we do often find that there multiple reasons why people ask about "clustering" or say they need scale-out:
A. Because you want to scale the amount of available storage - (we allow you to elastically add disks to scale-up the capacity on a single hypertable, have had customers scale a single hypertable to 500B rows)
B. Because you want high availability - (we support this today, via PostgreSQL streaming replication and will be documenting this further)
C. Because you want to support more concurrent queries -
(supported today across primary replicas)
D. Because you want to support high ingest rates - (depending on your use case, we have users doing 100-400k rows / second)
E. Because you want to parallelize individual queries (that touch a lot of data) - (some support for parallelization today, more to come)
So we do meet the needs of many today without support for full scale-out clustering (scaling vertically, as jurgenwerk points out). If your requirements are closer to millions of rows per second inserts and storing 100s of TBs / PBs of data, we can't yet support this, but working towards it!
The concept of a database built for time-series data specifically is in vogue lately (if you couldn't tell). Most of the TSDBs in the spreadsheet above, for instance, are NoSQL data stores designed for high ingest.
Full disclosure, we're also developing a new time-series database (http://www.timescaledb.com/) because we found the ones above achieved ingest scale by sacrificing query performance (and SQL). We needed something that had good ingest/query performance at scale (and we wanted to use pure SQL).