Live data from Hacker News

Show HN: pg_netstat, a Postgres extension to monitor database network traffic

github.com

11–20 of 26 posts

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#11
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.

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#12
post #9

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.

DB fan here who likes putting things into dbs. Are you guys hiring?

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#13

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.

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#14

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 clickhouse!

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#15
post #13

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.

+1 for Timescale. Used it for a few RNN projects and it's been great.

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#16
post #15
post #13

Earlier quoted context omitted.

Or just use TimescaleDB which is competitive on most axes but already PG.

+1 for Timescale. Used it for a few RNN projects and it's been great.

And I +1 your +1, we've been using it in prod for 2 years or so.

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#19

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?

Seems like they are: https://boards.greenhouse.io/supabase

Re: Show HN: pg_netstat, a Postgres extension to monitor database network traffic

#20
post #3

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've written a tool to do this not once but twice now! The first was for ingesting netflow data, the second from ingesting AWS VPC flow logs. In both cases this was storing 'flows' rather than raw packet information.

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.

Post reply on HN