Building a scalable time-series database on PostgreSQL
So, having played&#x2F;worked with a few time-series databases, this just doesn&#x27;t seem to fit the picture we&#x27;re used to.  For applications having to store a set of well-defined time-series in a more optimal way, it looks great. As a generic time-series database on the other hand, this sounds like a maintenance nightmare.<p>I quite like Postgresql (and deploy it all the time), and I&#x27;m no fan of nosql stuff, which just means you don&#x27;t have to properly analyze your database structure before-hand, but with time-series it&#x27;s different matter. The data you tend to send to generic time-series databases tends to be very unpredictable. I currently don&#x27;t care what data is sent to Prometheus or Influx. This includes, but is not limited to ZFS stats of our storage, system load, network traffic, VMWare, nginx&#x2F;haproxy, application usage and errors, ... I know that when I&#x27;ll need it, I&#x27;ll have it available and can try to correlate the data at any point in the future. In TimescaleDB it looks like I would have to pre-create tables fitting all those stats, which would make it an absolute pain in the ass.<p>As counter-intuitive as it sounds, to do it properly&#x2F;flexible&#x2F;usable in a real world, you should impose a fixed&#x2F;limited database structure. The tgres project mentioned elsewhere in this thread seems a lot more useful for &#x27;generic&#x27; cases. Maybe they can be combined in some way.<p>Also, some other important things in the time-series world are a REST api. Yes you might want advanced SQL to query data, but no you don&#x27;t want that to insert it. Pretty much any application can do http(s) stuff without any additional libraries (except when you&#x27;re talking about C&#x2F;C++ things). Postgres on the other hand? Oh no I need a JDBC driver for this Java app, I need an extra Python library for X, ... Not to mention you suddenly have to manage database pools in the applications and have something that is a potential bottleneck.<p>Then, no Grafana support is a no-go. It is the de-facto standard visualization tool these days.<p>What about retention policies, you don&#x27;t need ms-accurate data-points from 2 years ago, when talking about many data-points, you might want to aggregate this. Though since the data set in TimescaleDB will be limited due to specific data-sets, this could be less of a problem.