There was a post about timescale DB recently. Can you combine citusdb and timescale somehow to get super fast timeseries data and citus flexibility?
Citus and pg_partman: Creating a scalable time series database on Postgres
11–20 of 21 posts
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#12How well it performs compared to TimescaleDB ?
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#13The problem with Citus and TimescaleDB is that users can not install extensions on AWS RDS PostgreSQL.
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#14The problem with Citus and TimescaleDB is that users can not install extensions on AWS RDS PostgreSQL.
That's a problem with AWS RDS PostgreSQL, not with Citus and TimescaleDB.
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#15The problem with Citus and TimescaleDB is that users can not install extensions on AWS RDS PostgreSQL.
The answer to that is to use Redshift which is a proper distributed column-oriented data warehouse. Partion on time and let the database do the rest.
Using standard Postgres with sharding for OLTP workloads is great but there are better options for OLAP, especially if you’re using managed services. Also there is the Citus cloud offering if you want to stay with Postgres.
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#16The problem with Citus and TimescaleDB is that users can not install extensions on AWS RDS PostgreSQL.
The Citus Cloud service is similar to RDS, but for Citus clusters. Every cluster runs on AWS in its own VPC and it lets you peer with the VPC. It also provides auto-failover, PITR, forking, read-only followers and scaling out without any downtime.
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#17How well it performs compared to TimescaleDB ?
[deleted]
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#18How well it performs compared to TimescaleDB ?
In general I'd expect native partitioning to have similar performance characteristics as TimescaleDB. On the insert side lot of the benefit comes from partitions having small indexes, on the delete side from the ability to drop partitions quickly, and on the select side from skipping partitions based on filters.
Postgres 10 partitioning does have a few limitations and inefficiencies that will be resolved in Postgres 11. Partitioning is the most actively developed area of postgres.
Note that Citus shards across multiple nodes, and can then partition on disk using native partitioning, which is automated by pg_partman. TimescaleDB so far only works on a single node.
Citus can also run parallel, distributed SQL queries, perform distributed transactions, and build rollups tables in parallel, and is used in Postgres clusters with up to a petabyte of data.
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#19How well it performs compared to TimescaleDB ?
From everything I've seen on it, Citus makes horizontally scaling a multi-tenant database a transparent operation. This is ideal just because so many applications emphasize recency in the data that you don't want rarely accessed, 3 year old information cluttering up your indexes that are looking up things from this month 99% of the time.
Timescale seems to me more about the analytics side of things, focusing on ingestion speed and aggregation. Correct me if I'm wrong somebody.
Re: Citus and pg_partman: Creating a scalable time series database on Postgres
#20There was a post about timescale DB recently. Can you combine citusdb and timescale somehow to get super fast timeseries data and citus flexibility?
Craig from Citus here. From our cursory looks it does look like they could work together, though personally we've not tried it and I'm not aware of users that have (though it's entirely plausible some have already). What you'd have to do is setup timescale on each of your distributed nodes and tables. You'd still talk to Citus as the primary point and it would re-write and push the queries down to the nodes which could then leverage timescale.