Live data from Hacker News

PipelineDB 1.0 – High-Performance Time-Series Aggregation for PostgreSQL

pipelinedb.com

1–10 of 64 posts

Re: PipelineDB 1.0 – High-Performance Time-Series Aggregation for PostgreSQL

#3
post #2

I've been following Pipeline since the beginning and it's so fricking cool. Please, if you can't think of a good use of Pipeline, use it instead of a count(*)! :D

(Jeff, PipelineDB Co-Founder here) - thanks, Chucky! We appreciate your support!

Re: PipelineDB 1.0 – High-Performance Time-Series Aggregation for PostgreSQL

#8
post #4

Congrats! Also, how's stride.io doing?

I'm Derek, one of the co-founders--thank you!

We're super happy with where Stride is at! We've continued to onboard customers in a few AWS regions and the infrastructure is rock solid at this point. Most users are ingesting 10k+ events/s and their analytics frontends are retrieving results in well under 100ms. We've gotten it to the point where it "just works" which has made Stride users' lives a lot easier at that scale.

And since the hard parts of Stride are powered by PipelineDB, an added benefit for us is that we now get a ton of super detailed instrumentation data about PipelineDB performance and behavior, which has helped make the open-source product quite a bit better.

We'll be moving Stride into self-service/GA next year--stay tuned!

Re: PipelineDB 1.0 – High-Performance Time-Series Aggregation for PostgreSQL

#10
Looking over this cursorily, looks super cool.

    INSERT INTO events_stream (ts, value) VALUES (now(), '0ef346ac');
> As soon as the continuous view reads new incoming events and the distinct count is updated the reflect new information, the raw events will be discarded.

So you create a table, insert into it, and it's always empty. Is that right?

Does this work for any table in pg? How does pg know that the insert should NOT actually insert a row?

Post reply on HN