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).
As I mentioned inside the article, I tested last year version of TimescaleDB (July/August 2017) and that was my experience with it out of the box.
I am really impressed by all the progress you've made, and hopefully I'll consider TimescaleDB as my first choice on the next iteration of the product I'm working on.
Now, I'm skimming through the docs[1] and as I understand, create_hypertable is called before all the data is migrated, thus all TimescaleDB indexes are already present during the migration. What is the way to create indexes after data migration?
(1) Call create_hypertable with default indexes off (include an argument of `create_default_indexes => FALSE`) [1]
(2) Then just use a standard CREATE INDEX command on the hypertable at any time. B-Tree, hash index, GIN/Gist, single key, composite keys, etc. This DDL command will propagate to any existing chunks (and create them) and will be remembered to so any future chunks that are automatically created will also have these indexes [2]
>What is the way to create indexes after data migration?
You can migrate the data and then do the normal PostgreSQL `CREATE INDEX` syntax to create the indexes on the hypertable. It's not an option to create_hypertable or anything, but that's how you would achieve it.
How does Timescale solve the problem of retention. In InfluxDB, old data is thrown out at every tick as the retention window continuously rolls. In the world of Postgres, wouldn't this mean an explicit cron-like DELETE of rows all the time?
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.
