Postgres isn't a great TSDB - the indexes don't understand columns that will only have updates at one end, it doesn't do column compression, range queries are expensive, etc.
Perhaps it's time to just set up a time series database... Like influxDB.
11–20 of 26 posts
Postgres isn't a great TSDB - the indexes don't understand columns that will only have updates at one end, it doesn't do column compression, range queries are expensive, etc.
Perhaps it's time to just set up a time series database... Like influxDB.
Earlier quoted context omitted.
I'm curious as to how you're using these stats for monitoring. What kind of insights are you gaining with this, and in what context is it used?
Our price model based on database usage which includes db egress, so we use it to monitor db egress traffic just for now. We are all db fans and we like put things into db, so all the following processes, like searching, tracking, analysis and etc., are a lot easier.
Nearly all usecases for this seem to be recreating a time series database... Postgres isn't a great TSDB - the indexes don't understand columns that will only have updates at one end, it doesn't do column compression, range queries are expensive, etc. Perhaps it's time to just set up a time series database... Like influxDB.
Nearly all usecases for this seem to be recreating a time series database... Postgres isn't a great TSDB - the indexes don't understand columns that will only have updates at one end, it doesn't do column compression, range queries are expensive, etc. Perhaps it's time to just set up a time series database... Like influxDB.
Nearly all usecases for this seem to be recreating a time series database... Postgres isn't a great TSDB - the indexes don't understand columns that will only have updates at one end, it doesn't do column compression, range queries are expensive, etc. Perhaps it's time to just set up a time series database... Like influxDB.
Or just use TimescaleDB which is competitive on most axes but already PG.
Earlier quoted context omitted.
Our price model based on database usage which includes db egress, so we use it to monitor db egress traffic just for now. We are all db fans and we like put things into db, so all the following processes, like searching, tracking, analysis and etc., are a lot easier.
DB fan here who likes putting things into dbs. Are you guys hiring?
Hey HN, I have spent some time to search for a tool that can ingest realtime network traffic data to Postgres but have no luck, so I developed this extension and used it internally in our team. Thanks Rust, pgx and libpcap, the development journey is easy and enjoyable. Would like to hear more feedbacks. Any contributions, feature requests, bug report or ideas are welcomed. Thanks.
I'd be super interested in tooling to help with this. I'm running – literally right now – a Python script that is writing about 100k flows per second into Postgres (TimescaleDB). It is batch rather than realtime, and it geocodes the flows on the way in.