Processing high velocity time-series data in real-time is a complex challenge. The team at PipelineDB has built a continuous query engine that simplifies the task of computing aggregates across incoming streams of events. In this episode Derek Nelson and Usman Masood explain how it is architected, strategies for designing your data flows, how to scale it up and out, and edge cases to be aware of.
Hello and welcome to the Data Engineering Podcast, the show about modern data management
When you’re ready to build your next pipeline, or want to test out the projects you hear about on the show, you’ll need somewhere to deploy it, so check out Linode. With 200Gbit private networking, scalable shared block storage, and a 40Gbit public network, you’ve got everything you need to run a fast, reliable, and bullet-proof data platform. If you need global distribution, they’ve got that covered too with world-wide datacenters including new ones in Toronto and Mumbai. Go to dataengineeringpodcast.com/linode) today to get a $20 credit and launch a new server in under a minute.
Go to dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, read the show notes, and get in touch.
Join the community in the new Zulip chat workspace at dataengineeringpodcast.com/chat)
Your host is Tobias Macey and today I’m interviewing Usman Masood and Derek Nelson about PipelineDB, an open source continuous query engine for PostgreSQL
Introduction
How did you get involved in the area of data management?
Can you start by explaining what PipelineDB is and the motivation for creating it?
What are the major use cases that it enables?
What are some example applications that are uniquely well suited to the capabilities of PipelineDB?
What are the major concepts and components that users of PipelineDB should be familiar with?
Given the fact that it is a plugin for PostgreSQL, what level of compatibility exists between PipelineDB and other plugins such as Timescale and Citus?
What are some of the common patterns for populating data streams?
What are the options for scaling PipelineDB systems, both vertically and horizontally?
How much elasticity does the system support in terms of changing volumes of inbound data?
What are some of the limitations or edge cases that users should be aware of?
Given that inbound data is not persisted to disk, how do you guard against data loss?
Is it possible to archive the data in a stream, unaltered, to a separate destination table or other storage location?
Can a separate table be used as an input stream?
Since the data being processed by the continuous queries is potentially unbounded, how do you approach checkpointing or windowing the data in the continuous views?
What are some of the features that you have found to be the most useful which users might initially overlook?
What would be involved in generating an alert or notification on an aggregate output that was in some way anomalous?
What are some of the most challenging aspects of building continuous aggregates on unbounded data?
What have you found to be some of the most interesting, complex, or challenging aspects of building and maintaining PipelineDB?
What are some of the most interesting or unexpected ways that you have seen PipelineDB used?
When is PipelineDB the wrong choice?
What do you have planned for the future of PipelineDB now that you have hit the 1.0 milestone?
Podcast Episode)
[Podcast Episode](
Hive)
The intro and outro music is from The Hug) by The Freak Fandango Orchestra) / CC BY-SA)