Timescaledb: Amazon RDS, GCP Cloud SQL, Azure, Heroku support?
RDS comes with pre-packaged extensions... are there any talks with AWS to include timescale in their supported extensions, given that timescaledb uses the Apache 2.0 license?
jqnatividad
All 86 comments
Hi Joel, thanks for this question. We're connected with the folks at RDS but it's most helpful if they receive outside requests: https://aws.amazon.com/rds/postgresql/faqs/
Q: What are the extensions supported by RDS for PostgreSQL?
You can check the list of supported extensions in the Amazon RDS User Guide. To request support for additional extensions, you can send an email to [email protected] with the extension name and use case.
We would also recommend that you ask your AWS Account Manager for the TimescaleDB extension to be made available on RDS.
Would then be useful if you could let us know (privately) their feedback and we can reassess how to expedite the process of becoming an extension. Hope this helps.
[UPDATE] We've received many other requests to be supported on GCP Cloud SQL, Heroku, and Azure, so we wanted to list the appropriate places to submit extension requests for those platforms here, along with RDS, and keep the information in one place.
stalltron
on 26 May 2017
@mfreed do you know if there's an update about this?
orlando
on 29 Aug 2017
Hi @orlando we haven't announced a timeline and some of it is out of our control. We'll provide updates as we have them.
stalltron
on 6 Sep 2017
Thanks @stalltron, having that will be a huge win for timescaledb. Last week I tried it with metabase and works OTB (expected since is still postgres) but it was really good to have graphs from a time series database in less than 10 minutes
orlando
on 6 Sep 2017
Is it possible to run TimescaleDB as a "frontend" on a separate machine that connects to an RDS instance?
misham
on 8 Nov 2017
@misham Interesting question.. We can be run on EC2, so the question then becomes can hosted offerings like RDS be run alongside self-managed EC2 instances? I'm not entirely sure, but will look into this...
stalltron
on 17 Nov 2017
If you're looking into using RDS as a slave and PG running as master on an EC2 instance, that doesn't work - at least I haven't been able to figure out how to make that work.
I was wondering if it's possible to make TimescaleDB run as a separate service that uses PG as a "backend" and then have the app talk only to TimescaleDB.
misham
on 17 Nov 2017
@misham Ah, ok. Can you share more about the use case you have in mind? I'm not sure I understand "uses PG as a backend," since data stored in TimescaleDB is effectively stored in PostgreSQL. Please email me ([email protected]) if there's stuff you can't share publicly.
stalltron
on 17 Nov 2017
This is exactly the use case I have.
So the idea is you have a clustered TimescaleDB service living in AWS EC2 (presumably an autoscaling group), that's load balanced (I'm new to this tool and I'm just assuming this can be done) and that that clustered service is configured to point to an RDS endpoint for storage.
I'm a little surprised that this isn't something timescaleDB can't do today out of box. It seemed obvious to me that such a tool would be able to consume arbitrarily defined PostgreSQL backends for storage; is this not the case?
I've only _just_ discovered this tool, so forgive my ignorance, but my initial assumption was that I'd see some kind of config file where the default postgresql location is set to localhost, but can be configured as necessary. If this can't be done today then it strikes me as a necessary, and very basic, feature.
This would solve the problem of people seeking support for database services on every possible hosting platform without needing the input of those hosting platforms, and it's a pretty commonly expected behavior from any tooling that writes to/reads from a database (that is, the ability to configure the database endpoint/connection-string/credentials/terminology-of-choice).
TalosThoren
on 4 Dec 2017
@TalosThoren TimescaleDB is not a service that sits in front of a database, is a PostgreSQL extension (ex. PostGIS) you install to add new capabilities to it (http://docs.timescale.com/latest/using-timescaledb/hypertables). You can do it without problems since you are using EC2, but with managed services like RDS is not possible yet (AWS needs to whitelist the extension first).
Or maybe I'm not getting what you are trying to say
orlando
on 4 Dec 2017
@orlando, that makes perfect sense and explains the limitations preventing this from being deployed in my expected use case. Thank you for clarifying.
TalosThoren
on 4 Dec 2017
Thank you @orlando, that is correct.
@TalosThoren - If you'd like to expedite the AWS whitelisting process, please feel free to follow the instructions at the top of this issue.
Thanks!
akulkarni
on 4 Dec 2017
Might as well add Aliyun to that list.
They wrote multiple blogs but not supported in official pg extensions.
lambdaq
on 25 Jan 2018
Update: I contacted Aliyun (AlibabaCloud) support via ticket system (https://workorder.console.aliyun.com), their response is
以上您建议我们会评估分析一下关于功能需求，但是目前还没有得到评估计划、相关功能是否可以支持及确认支持时间。
Translation: We will evaluate this, but we dont have a plan or confirmation yet.
List of installed plugins are:
psql (9.2.23, server 9.4.10)
WARNING: psql version 9.2, server version 9.4.
Some psql features might not work.
Type "help" for help.
db=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(1 row)
db=> SELECT * FROM pg_available_extensions;
name | default_version | installed_version | comment
------------------------------+-----------------+-------------------+---------------------------------------------------------------------------------------------------------------------
address_standardizer | 2.2.2 | | Used to parse an address into constituent elements. Generally used to support geocoding address normalization step.
chkpass | 1.0 | | data type for auto-encrypted passwords
test_shm_mq | 1.0 | | Test code for shared memory message queues
postgis_topology | 2.2.2 | | PostGIS topology spatial types and functions
pgrowlocks | 1.1 | | show row-level locking information
jsonbx | 1.0 | | Jsonb extension
pg_hint_plan | 1.1.3 | |
dblink | 1.1 | | connect to other PostgreSQL databases from within a database
adminpack | 1.0 | | administrative functions for PostgreSQL
earthdistance | 1.0 | | calculate great-circle distances on the surface of the Earth
plperlu | 1.0 | | PL/PerlU untrusted procedural language
plcoffee | 1.4.2 | | PL/CoffeeScript (v8) trusted procedural language
tcn | 1.0 | | Triggered change notifications
pg_freespacemap | 1.0 | | examine the free space map (FSM)
timetravel | 1.0 | | functions for implementing time travel
oss_fdw | 1.1 | | foreign-data wrapper for flat file access
plls | 1.4.2 | | PL/LiveScript (v8) trusted procedural language
imgsmlr | 1.0 | | image similarity module
intarray | 1.0 | | functions, operators, and index support for 1-D arrays of integers
pg_sphere | 1.0 | | spherical objects with useful functions, operators and index support
varbitx | 1.0 | | varbit functions pack
pgrouting | 2.0.0 | | pgRouting Extension
pageinspect | 1.2 | | inspect the contents of database pages at a low level
pgstattuple | 1.2 | | show tuple-level statistics
intagg | 1.0 | | integer aggregator and enumerator (obsolete)
citext | 1.0 | | data type for case-insensitive character strings
ali_decoding | 0.0.1 | | ali_decoding
insert_username | 1.0 | | functions for tracking who changed a table
xml2 | 1.0 | | XPath querying and XSLT
postgis | 2.2.2 | | PostGIS geometry, geography, and raster spatial types and functions
pgcrypto | 1.1 | | cryptographic functions
pltclu | 1.0 | | PL/TclU untrusted procedural language
pg_stat_statements | 1.2 | | track execution statistics of all SQL statements executed
orafce | 3.6 | | Functions and operators that emulate a subset of functions and packages from the Oracle RDBMS
hstore | 1.3 | | data type for storing sets of (key, value) pairs
lo | 1.0 | | Large Object maintenance
plperl | 1.0 | | PL/Perl procedural language
q3c | 1.5.0 | | q3c sky indexing plugin
postgres_fdw | 1.0 | | foreign-data wrapper for remote PostgreSQL servers
zhparser | 1.0 | | a parser for full-text search of Chinese
tablefunc | 1.0 | | functions that manipulate whole tables, including crosstab
refint | 1.0 | | functions for implementing referential integrity (obsolete)
pg_prewarm | 1.0 | | prewarm relation data
btree_gin | 1.0 | | support for indexing common datatypes in GIN
autoinc | 1.0 | | functions for autoincrementing fields
postgis_tiger_geocoder | 2.2.2 | | PostGIS tiger geocoder and reverse geocoder
test_parser | 1.0 | | example of a custom parser for full-text search
pg_buffercache | 1.0 | | examine the shared buffer cache
btree_gist | 1.0 | | support for indexing common datatypes in GiST
fuzzystrmatch | 1.0 | | determine similarities and distance between strings
moddatetime | 1.0 | | functions for tracking last modification time
address_standardizer_data_us | 2.2.2 | | Address Standardizer US dataset example
tsearch2 | 1.0 | | compatibility package for pre-8.3 text search functions
worker_spi | 1.0 | | Sample background worker
pg_awr | 1.0 | | PostgreSQL awr
pltcl | 1.0 | | PL/Tcl procedural language
file_fdw | 1.0 | | foreign-data wrapper for flat file access
smlar | 1.0 | | compute similary of any one-dimensional arrays
www_fdw | 0.1.8 | | WWW FDW - extension for handling different web services
rdkit | 3.4 | | Cheminformatics functionality for PostgreSQL.
plpythonu | 1.0 | | PL/PythonU untrusted procedural language
ltree | 1.0 | | data type for hierarchical tree-like structures
dict_int | 1.0 | | text search dictionary template for integers
unaccent | 1.0 | | text search dictionary that removes accents
uuid-ossp | 1.0 | | generate universally unique identifiers (UUIDs)
pg_trgm | 1.1 | | text similarity measurement and index searching based on trigrams
plpgsql | 1.0 | 1.0 | PL/pgSQL procedural language
plpython2u | 1.0 | | PL/Python2U untrusted procedural language
seg | 1.0 | | data type for representing line segments or floating-point inte rvals
plv8 | 1.4.2 | | PL/JavaScript (v8) trusted procedural language
dict_xsyn | 1.0 | | text search dictionary template for extended synonym processing
cube | 1.0 | | data type for multidimensional cubes
sslinfo | 1.0 | | information about SSL certificates
isn | 1.0 | | data types for international product numbering standards
(74 rows)
@orlando
TimescaleDB is not a service that sits in front of a database, is a PostgreSQL extension (ex. PostGIS) you install to add new capabilities to it (http://docs.timescale.com/latest/using-timescaledb/hypertables).
Let's think about this, it's ok to setup a pg isntance on ec2, however, the main problem is the extremely low IOPS.
What if we can setup a pg broker with timescale extension on ec2, but we don't do data persistency on broker, instead we use hosted RDS to do the heavy-lifting for actual read/writes.
The pg broker instance is only for query planing.
Is this doable?
lambdaq
on 26 Jan 2018
@lambdaq Thanks for reaching out to Aliyun and providing that data.
I should also add that TimescaleDB currently supports Postgres version 9.6 and 10. It looks like at least the version of the Aliyun PG instance you are using is 9.4 (which was released in late 2014), but we don't currently have any plans to backport to 9.4.
mfreed
on 27 Jan 2018
@lambdaq Regarding your postgres broker idea, is there a particular software codebase you are referring to? Timescale can be utilized with remote storage via FDW, but also does run "inside" a Postgres database instance itself.
That said, I'm not sure I follow/agree with the assumption behind your question, which is that PG databases deployed on EC2 suffer from low IOPS. This seems mostly due to the type of storage selected with EC2: local SSD, remote SSD, remote HDD, provisioned vs. unprovisioned IOPS, etc.
We've certainly had no problems reaching steady-state traffic rates of 100K+ rows / second on these cloud VMs with the modest provisioning of network-attached SSD.
mfreed
on 4 Feb 2018
I've contacted AWS RDS multiple times via email to request TimeScale support... no response
rymoore
on 13 Feb 2018
I've sent requests to Heroku and AWS RDS, please if this is relevant to you, reach out! It takes 5 minutes!
latortuga
on 20 Apr 2018
@latortuga Best way to send feature requests to AWS?
selbyk
on 27 Apr 2018
There are lots of links up this issue thread.
On Fri, Apr 27, 2018, 3:21 PM Selby Kendrick notifications@github.com
wrote:
@latortuga https://github.com/latortuga Best way to send feature
requests to AWS?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/timescale/timescaledb/issues/65#issuecomment-385083806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAko40th6QBlnBb37Qk8g6D5fiXqWkEks5ts33ggaJpZM4Nn5rR
.
latortuga
on 28 Apr 2018
It looks like Aiven recently added TimescaleDB support to their cloud managed Postgres option. Not affiliated and haven't tried them yet.
rawberg
on 12 May 2018
I've raised a ticket with AWS support to request this, and I'll also email the Aurora Postgresql Product manager to follow this up and see what he says.
craiggenner
on 21 Jul 2018
I've had this response to my ticket:
"To request support for additional extensions/plugins, you can send an email to [email protected] with the extension/plugin name and use case. "
My request has been put to the team though (along with the rest)
craiggenner
on 21 Jul 2018
sent an email to that AWS account too without a response but that seems to be the way that works. Wonder how this topic hasn't come forward after over a year of "contact" with the AWS RDS team @stalltron @mfreed - are they declining to bring TimescaleDB on or is there just work to be done? Can you give any status update or outlook? Any chance to see timescaleDB on RDS anytime soon?
Helmi
on 31 Aug 2018
I met with some members of the RDS team and it would appear its more likely they have so many core features they want to implement first.
But yes don't expect a reply to the email address.
craiggenner
on 2 Sep 2018
I've also emailed [email protected] and will bring up with our AWS account rep - would love to see this get supported!
jwg2s
on 18 Sep 2018
Yes, would like to see this as well. We are sticking to Postgres as of now for over a year (and come back to this page once a month), primarily because timescale isnt supported by RDS.
Hoping for the best.
ashwinpromethean
on 28 Sep 2018
I met an AWS Account Manager yesterday and he adds us as customer reference to this feature requirement.
No garanties but that should contribute.
mmouterde
on 9 Oct 2018
Please go add a comment to the AWS forums so they would speed up the integration here: https://forums.aws.amazon.com/thread.jspa?messageID=799694󃏎
maksimluzik
on 18 Oct 2018
Any update on this? Would love to help in anyway I can to speed this along. I’ve created tickets at AWS and Heroku for this but no response
austinh
on 9 Nov 2018
Digital Ocean has released Managed Databases. We might have a chance to see a positive response from them.
sachaarbonel
on 13 Nov 2018
This is probably the reason why AWS isn't supporting this postgres extension for RDS: Amazon Timestream: https://aws.amazon.com/timestream/?hp=r
pjebs
on 12 Dec 2018
This is probably the reason why AWS isn't supporting this postgres extension for RDS: Amazon Timestream
AWS has other competing products so I'm still hoping to see Timescale supported in RDS PG extensions.
alanhamlett
on 16 Dec 2018
What does the new license mean for these integrations?
Tyler-Murphy
on 4 Jan 2019
AFAICT it simply means that they should pay TimescaleDB to provide their customers the extension in an "as a service" manner.
That of course is a reasonable decision on TimescaleDB's side as they want to profit as well on that case BUT it will make integrations harder to happen as it'll cost all those service providers more and they'll have to pass the cost to the end customer at the end. On top of that, AWS especially is rumored to not actually play well with others.
On the other hand there is a lot of discussion in the OSS community for that kind of licensing. Mongo's decision and actual license seems like it backfired in the end (?) (see
https://www.theregister.co.uk/2019/01/17/red_hat_mongodb/)
It's interesting to see what's going to happen. It's important for all these data related businesses to find a way to profit because the won't survive otherwise (see Riak) and that's a problem for the community that wants to avoid vendor lock-in and trust some stable tech that will not extinguish in the next couple of years.
mehiel
on 21 Jan 2019
To be clear, the various cloud providers can certainly deploy the Apache 2 version of TimescaleDB; all capabilities to date have been licensed _and remain available_ under the Apache 2.
That has been one confusion about the announcement of the Timescale License. Unlike Mongo and Confluent, _we did not relicense code_ from the Apache 2 to TSL. We simply "preannounced" that some future capabilities will be licensed under something different than the Apache 2.
What this does mean is that these _future_ capabilities that are TSL licensed can't be deployed by the DBaaS / cloud providers, without some additional commercial relationship with Timescale. The cloud providers will continue to be able to deploy the OSS version of TimescaleDB.
mfreed
on 21 Jan 2019
Thanks for the clarifications @mfreed.
TimescaleDB's decision seems way more balanced and I think they'll be welcomed by both the community and the cloud providers. Time will tell. Keep it up!
mehiel
on 22 Jan 2019
First of all I understand that people behind timescale want to make a living and the decision behind TSL and so on, yet afaik that is a deathshot for all dreams of getting Timescale on AWS / GCP / ...
No cloud provider will install it when by any chance a future version might
a) have an addon or whatever bundled with this TSL. It would open the doors for a potential lawsuit and is just not worth the trouble.
b) tomorrow you would decide that only your TSL version would support Postgres 10, then that would mean that they would not be able to upgrade to Postgres 10 or would have to get a shitstorm from all their customers. (this also applies to all other potential restrictions that you might add to a new timescaledb version)
You can argue whatever you like about "It wont happe" or "they can still use the apache 2.0" ...
It just does not matter to them. Also to have this discussion here now does not really matter anymore. The guys behind timescaledb for sure knew all of that when they made the decision and made it anyway, fully accepting this.
So if you want it, you have to host it yourself.
chickahoona
on 22 Jan 2019
Yo AWS RDS people, Azure is going to do it. How about you ?
AZURE: "
Unplanned → Planned
We’ve been working with TimescaleDB team to enable it in Azure Database for PostgreSQL service. We expect TimescaleDB extension to be available to customers of our service worldwide in 6-8 weeks from now.
Nik on behalf of the Azure Database for PostgreSQL team
| Azure Database for PostgreSQL Product TeamAdmin, Microsoft Azure
"
windbender
on 23 Jan 2019
Citus acquisition then this ^.
There is something happening for sure with MS :) Good news!
mehiel
on 24 Jan 2019
I'll believe it when I see it.
It's a shame they won't implement it for a non-Aurora postgres RDS. Aurora is too expensive for my use case.
pjebs
on 24 Jan 2019
They have timescaledb on aurora RDS?
austinh
on 24 Jan 2019
@austinh It's supposedly a few weeks away. But I'll believe it when I see it.
pjebs
on 24 Jan 2019
I would really love TimescaleDB to be available on Digital Ocean.
chanon
on 28 Jan 2019
Any update on this? Would love to help in anyway I can to speed this along. I’ve created tickets at AWS and Heroku for this but no response
I submitted a ticket request for timescale add-on to Heroku as well.
JeroneGagliano
on 13 Feb 2019
I think Digital Ocean will be more receptive from a business perspective. They just launched their managed service and it's a great opportunity to bring in new customers Immediately:https://blog.digitalocean.com/announcing-managed-databases-for-postgresql/
@akulkarni
pjebs
on 14 Feb 2019
@pjebs no need to be hopeful as it is already confirmed that the DigitalOcean Managed Database offering contains Timescale as plugin option by default in the status quo as of today :-)
https://gist.github.com/peterc/e4f7a288ed0eb7e4ffe2d8383a086306
consense
on 14 Feb 2019
ehamberg
on 15 Feb 2019
Still not supported at AWS, anybody know when it might be?
I also don't see it over at Azure:
https://docs.microsoft.com/en-us/azure/postgresql/concepts-extensions
Anything new on MS support?
edencorbin
on 27 Feb 2019
@edencorbin, for Azure follow this feedback issue. They said 6-8 weeks January 23rd. So worst case - if they follow that timeline - we should see it by the end of March.
bremnes
on 27 Feb 2019
Azure has shipped support!
https://azure.microsoft.com/en-us/blog/power-iot-and-time-series-workloads-with-timescaledb-for-azure-database-for-postgresql/
SamWoolerton
on 18 Mar 2019
Alibaba has recently posted a bunch of tutorials on how to use TimescaleDB on their cloud: https://www.alibabacloud.com/blog/postgresql-time-series-database-plug-in-timescaledb-deployment-practices_594814
mfreed
on 19 May 2019
Additionally, this perhaps goes without saying, but a managed version of TimescaleDB is now available on the Timescale Cloud on both AWS and Google Cloud. It includes all enterprise capabilities and billed at an incremental hourly cost.
mfreed
on 19 May 2019
In the meantime, if anyone can make a tutorial on how to run timescale with the self managed version of AWS, where you do everything manually, it would be super appreciated, what is it called, EBS?
slidenerd
on 18 Jun 2019
Any updated ETA for TimescaleDB on AWS RDS?
ryanrolds
on 1 Jul 2019
I thought timescaleDB was already working on AWS RDS for postgres. There
are installation instructions on timescale's website for postgres 11.
On Mon, Jul 1, 2019, 1:33 AM Ryan Olds notifications@github.com wrote:
Any updated ETA for TimescaleDB on AWS RDS?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/timescale/timescaledb/issues/65?email_source=notifications&email_token=AICJFGXMSDPZMDVYBMPLVM3P5GJMJA5CNFSM4DM7TLI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY5BAQY#issuecomment-507121731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AICJFGXSRJVSSRI7ACXFFGDP5GJMJANCNFSM4DM7TLIQ
.
JeroneGagliano
on 1 Jul 2019
Do you have a link? I don't see any for AWS RDS, just setting up a cluster outside of RDS.
ryanrolds
on 1 Jul 2019
Maybe I'm misunderstanding it, but these instructions AR for installing
postgres on and AWS AMI and then connecting it to your postgres database?
https://docs.timescale.com/v1.3/getting-started/installation/ami/installation-ubuntu-ami
I have a postgres database setup on RDS and I'm really hoping to use
timescale for my project as well.
On Mon, Jul 1, 2019, 9:53 AM Ryan Olds notifications@github.com wrote:
Do you have a link? I don't see any for AWS RDS, just setting up a cluster
outside of RDS.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/timescale/timescaledb/issues/65?email_source=notifications&email_token=AICJFGUBUBNCKHU5NL7OYBTP5ID5LA5CNFSM4DM7TLI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY6GF7Q#issuecomment-507273982,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AICJFGQEUYRTKAINXLAA7FLP5ID5LANCNFSM4DM7TLIQ
.
JeroneGagliano
on 1 Jul 2019
Those instructions appear to be for setting up a PG instantace with Timescale DB on EC2 instances using pre-built images, not using RDS.
ryanrolds
on 1 Jul 2019
Oh, thank you for the clarification. That's a real bummer.
On Mon, Jul 1, 2019, 10:14 AM Ryan Olds notifications@github.com wrote:
Those instructions appear to be for setting up a PG instantace with
Timescale DB on EC2 instances using pre-built images, not using RDS.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/timescale/timescaledb/issues/65?email_source=notifications&email_token=AICJFGUOSX5LZD6MDDRQIELP5IGL7A5CNFSM4DM7TLI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY6IITA#issuecomment-507282508,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AICJFGTFQXI3A5LZTSN7SRTP5IGL7ANCNFSM4DM7TLIQ
.
JeroneGagliano
on 1 Jul 2019
In case there is any confusion on this front, here's the current state of things as of the time I posted this (that I know of):
AWS - No support
GCP - No support
Azure - TimescaleDB OSS only
Alibaba - TimescaleDB OSS only
Digital Ocean - TimescaleDB OSS only
Timescale Cloud - TimescaleDB Enterprise
dianasaur323
on 16 Jul 2019
How would you go about connecting to a TimescaleDB running on an EC2 or Lightsail instance from a Lambda function?
Drkstr
on 30 Aug 2019
I sent another request to [email protected] is there anything you want us to include in the request?
How would you go about connecting to a TimescaleDB running on an EC2 or Lightsail instance from a Lambda function?
you could do that but it's not a managed service anymore.. only good for side projects.
EralpB
on 18 Sep 2019
AWS are working on their managed timeseries database, Timestream, that will be released probably in a few months.
So I don't expect them to accept any timeseries integration with RDS.
forzagreen
on 18 Sep 2019
AWS are working on their managed timeseries database, Timestream, that will be released probably in a few months.
So I don't expect them to accept any timeseries integration with RDS.
earlier this year they've sent me an email when I've asked about timescaledb support saying:
This is definitely on our 2019 roadmap for RDS Postgres 11
alex88
on 30 Sep 2019
Any news about AWS support ?
throrin19
on 30 Oct 2019
Waiting for OSS version on AWS RDS
🤓
rskumar
on 5 Nov 2019
Regarding AWS, got the following reply after requesting Timescale support to the email address mentioned above:
"L*, D*" <l***@amazon.com>
This is on our roadmap for 2020.
So it seems that support from RDS was delayed a bit.
punnie
on 11 Nov 2019
any news already?
solars
on 14 Feb 2020
@solars, our team started to use https://www.timescale.com/cloud/ in AWS which we tunnel within the VPC. the self serve portal is simple and straight forward.
sairam
on 14 Feb 2020
You can even terraform it using the provider created by aiven. It works great and the pricing is much on par with what RDS offers.
Sytten
on 14 Feb 2020
In my case I have a specific cloudformation using the latest timescaleDB AMI.
This cloudformation create :
- 1 HAproxy server
- 1 etcd server
- 3 timescleDB servers with patroni to manage cluster and replication primary/secondary on down
throrin19
on 14 Feb 2020
Thanks for the pointers, we have our infrastructure on AWS (EC2 in Germany). The timescale cloud option seems nice, but if I compare costs right now it's much more expensive (we're at the lower side of the offers).
solars
on 19 Feb 2020
@solars , one suggestion we got during our onboarding was a possibility to move the complete database infra to avian hosted timescaledb since they support regular database tables as well on the new server instance.
The amount of data reduction may help based on your usecase too which would save on the disk space usage.
Cheers,
sairam
on 19 Feb 2020
Any update about this? :thinking:
sytabaresa
on 14 Apr 2020
It's really a bummer that you still cannot use TimescaleDB on RDS :(
silentlight
on 19 Apr 2020
It's really a bummer that you still cannot use TimescaleDB on RDS :(
Most likely because such an extension causes direct conflict of interest with AWS’ own https://aws.amazon.com/timestream/
djrobby
on 4 May 2020
Not sure where to post this. It looks like this issue is the best fit.
We are discussing Timescale over at Supabase: https://github.com/supabase/postgres/issues/5#issuecomment-636893064
☝️ This repo packages Postgres with other useful extensions. It's unclear whether we can offer this based on the licensing terms. The main reason is that Supabase has a hosted platform ourselves. We only want to package extensions which our customers can use too.
Is there anyone in the Timescale team that we can chat to about this? I see a number of benefits for Timescale - our images make it extremely easy to get started with Postgres and try out different extensions. We already have Docker, Digital Ocean, AWS, with more platforms on the way.
kiwicopple
on 3 Jun 2020
In case there is any confusion on this front, here's the current state of things as of the time I posted this (that I know of):
AWS - No support
GCP - No support
Azure - TimescaleDB OSS only
Alibaba - TimescaleDB OSS only
Digital Ocean - TimescaleDB OSS only
Timescale Cloud - TimescaleDB Enterprise
I was interested in using TimescaleDB in Alibaba Cloud, which is mentioned as available here. But I don't seem to find it in ApsaraDB PostgreSQL docs. It seems like the article mentioned by another is discussing how to use timescaleDB in a self-managed VM instead of managed PosgreSQL DB like the Apsara. Any thoughts?
benedictjohannes
on 12 Jun 2020
Hi @kiwicopple I just saw your comment. Could you email me at ajay (at) timescale.com?
akulkarni
on 25 Jul 2020
Hi all - Timescale Cloud is now available on AWS, GCP, and Azure in over 75 regions: https://www.timescale.com/cloud
It is the only hosted service where you can get the full TimescaleDB experience: native compression, continuous aggregations, data retention policies, etc. These features aren't available on other hosted services. So even if AWS were to offer TimescaleDB, you wouldn't be getting the key TimescaleDB features.
In particular, most of our users with compression are seeing over 96% storage savings, which often can make Timescale Cloud cheaper than the equivalent on RDS (and others).
Hope this helps!
akulkarni
on 25 Jul 2020
@akulkarni I really appreciate the hard work that has been put in building this awesome product. I'm inclined on the hosted / managed TimescaleDB service, but one concern is holding me back.
My use case would be a small sized infrequent-insert very-frequent-access IoT sensor reading. For this, I would rather have a low CPU count, small storage but large RAM (due to almost all FLOAT columns). I can imagine other use cases like web scrapping data warehouse that can produce very large (TEXT) data per row that would need large storage (but not large RAM).
Please correct me if I'm wrong: When I'd like to launch hosted TimescaleDB solution, I found that the configuration offered when I see the pricing page is rather limited, and it restrict my option that (I reckon) can result in more deployment cost saving, thus using hosted TimescaleDB might (probably) result in unnecessary cost due to unnecessary resource provisioning.
If full machine type flexibility can be added, it would practically wipe _this_ concern away.
benedictjohannes
on 30 Jul 2020
Hi @benedictjohannes - sorry for the delayed response.
Given your concern for more fine-tuned provisioning, have you considered Timescale Forge? https://www.timescale.com/forge
We recently launched Forge as a second hosted service to complement Timescale Cloud. It allows you to independently scale compute/storage (among other advanced features). (However, unlike Timescale Cloud, it does not let you choose which cloud/region to operate in.)
Let me know if that can do the job. Cheers!
akulkarni
on 11 Aug 2020
@benedictjohannes Forgot to add: We get great compression for floats, which will also reduce your resource requirements: https://docs.timescale.com/latest/using-timescaledb/compression
akulkarni
on 11 Aug 2020
@akulkarni I've looked on Timescale Forge link. It certainly looks promising, I'll have a closer look. But it would be even better if the cloud service is more flexible.
Or, maybe timescale can be offered directly as service through the cloud platform (GCP marketplase in my case), maybe like how Redhat offers RHEL?
benedictjohannes
on 13 Aug 2020
Related issues
matti
·
4Comments
jensenbox
·
4Comments
100milliongold
·
5Comments
Manjureka
·
4Comments
vanwalj
·
5Comments
Most helpful comment
Hi Joel, thanks for this question. We're connected with the folks at RDS but it's most helpful if they receive outside requests: https://aws.amazon.com/rds/postgresql/faqs/
We would also recommend that you ask your AWS Account Manager for the TimescaleDB extension to be made available on RDS.
Would then be useful if you could let us know (privately) their feedback and we can reassess how to expedite the process of becoming an extension. Hope this helps.
[UPDATE] We've received many other requests to be supported on GCP Cloud SQL, Heroku, and Azure, so we wanted to list the appropriate places to submit extension requests for those platforms here, along with RDS, and keep the information in one place.