stalller

relative to more mature Kafka cloud services, it's crazy expensive.

It is encouraged! :)

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).

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

Thanks for the recommendation of Timescale :)

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!