How Density Manages Large Real Estate Portfolios Using Timescale
Industry IoT
Company Density
Customer Cloud
Density helps its customers, from Fortune 100 to high-growth tech companies, improve employee experience and reduce their carbon footprint. Density’s platform can reveal if employees are choosing focus space or collaborative space, which floors are the most popular (and why), and how one office’s occupancy rate compares to others in a portfolio or against industry benchmarks. Density’s technology is helping inform decisions for the workplaces of some of the largest companies in the world, spanning 32 countries, with more than 1.25 billion square feet under management.
The Challenge of High Manual Effort Before Timescale
Density originally built an entire time-series database using stored procedures and vanilla PostgreSQL. It was difficult to query the data and enable customers to slice it up into multiple dimensions. It was not as simple to operate large query plans for vanilla PostgreSQL and trim them down to something predictable, reasonable and operated at relatively low latencies. Development was not as fast as it could be, and they had to manage decision logic and complexity around time zone handling and bucketing themselves.
Why Density chose Timescale
Brock Friedrich, a software engineer on the Density team, had previous experience with Timescale while working at an oil and gas firm and researching time-series storage options. Once the Density team realized they needed a time-series database, they began to evaluate options. Timescale came out as a clear winner, as the tolerance for high insert rates exceeded the team’s expectations. Plus, the similarity to vanilla PostgreSQL made it simple to adopt. These were huge wins both operationally and development-wise—Density can always fall back on core PostgreSQL principles or relational data models but also dive deeper into Timescale’s specific functionality to meet big time-series use cases.
How Density uses Timescale
Density uses different types of data at different stages. Their entry sensors generate infrared data that is very dense. As it’s not feasible to send this dense data to the cloud, all processing and machine learning is done at the edge (on the device). This results in +1/-1 counts that can be aggregated in their pipelines and Timescale. Density’s radar-based sensors generate sparse data, so they do less processing at the edge and more in the backend. This data goes through a pipeline and gets transformed before inserting it into Timescale and performing any aggregations. Density uses it not just for the continuous aggregates of count data but also the bucketing. Whenthis is handled in TimescaleDB, the Density team is able to get the right data the way they want it.
Results
Timescale’s flexibility and ability to handle large volumes of data reduced the manual effort and slow queries with vanilla PostgreSQL. The bucket function returns the right size buckets that they need and handles the difficulties of time zones and daylight savings time. Timescale can ingest the amount of data they needed, a struggle the team faced with vanilla PostgreSQL. Density found that Timescale is dynamic—they can slice and dice queries in a more or less arbitrary number of ways. Timescale’s flexibility and ability to do partitioning and hypertables to quickly access data back in time is a winning combination for their use case. When Density began to use the platform, Timescale made development significantly faster. Continuous aggregates also enabled them to roll up multiple resolutions of sensor account data, people count data, and make it available more efficiently with little to no effort related to the code that they had to write to deliver those efficiencies.
I get the most pride in doing plain SQL against TimescaleDB, getting time-series results at scale, and not having to do a bunch of backflips.
Brock Friedrich,
Software Engineer at Density
