This is an installment of our “Community Member Spotlight” series, in which we invite our customers to share their work, spotlight their success, and inspire others with new ways to use technology to solve problems.
In this edition, Per Grapatin, Vice-President of Engineering at
About the Company & Team
I’m Per Grapatin, Vice President of Engineering at Glooko, a diabetes platform used by over 1M patients for glucose monitoring and chronic condition tracking. We simplify diabetes care, integrate with EHR workflows, and deliver measurable health outcomes.
Glooko ingests over 100M new data points every day, primarily timestamped measurements and patient events, to power real-time dashboards and analytics for patients and healthcare providers. Older devices collect glucose values every 5 minutes, newer ones every minute. To meet local data residency requirements, we utilize regional data centers in Germany, Ireland, Canada, and the U.S. for storage and analytics.
The Challenge: Scaling time-series workloads with existing infrastructure
Real-time time-series workloads force ugly cost/performance trade-offs. You can buy your way out of performance bottlenecks, but it gets expensive fast. At Glooko, we hit the point where scaling our existing setup to keep up with rising demand just wasn’t worth the cost.
- Sluggish ingestion: 74B+ total CGM records and 100M+ new readings per day were pushing our document database to its limits.
- Data bloat: Existing document database cluster had grown to 30 TB, largely due to index overhead.
- Slow queries: 14-day and 90-day rollups were too slow for clinicians, and performance worsened as data grew.
- No retention policies: Every new measurement was stored permanently, further driving up costs and footprint.
Replacing NoSQL with Tiger Data
As we evaluated alternatives to our existing document database, Tiger Data stood out. We already trusted Postgres internally and had considered building our own time-series solution on it, but were uneasy about the risks of self-hosting a tech stack requiring HIPAA/GDPR compliance. In addition, we use AWS as the backbone of our digital system, so Tiger Data’s model running on EC2 with S3 storage made it easy to snap into our existing architecture.
With
- Optimized for time-series: Managed Postgres with purpose-built time-series extensions, including incremental materialized views and automatic partitioning.
- Cost savings: Policy-based compression and retention for automated data lifecycle management.
Unified Postgres Architecture Resolved Ingest and Read Bottlenecks
We unified everything on Tiger Cloud and kept it in a single Postgres platform, with compute and storage decoupled. That cleared our ingest/read bottlenecks without our costs exploding, and it gives us room to scale while shipping more functionality.
We designed new TimescaleDB hypertables around how we actually query per patient, per day. We kept only the fields we needed for analytics in the hot path and pushed the rest to cheaper storage. With this shift, query patterns now match the time-series partitioning relevant for clinicians and patients consuming the data (e.g. “Show me the last 90 days”, etc). Late-arriving data and continuous writes to recent time windows now occur in a normal, supported pattern rather than being managed on an ad-hoc basis.
In addition, we built a dedicated medical data service (MDS) with direct access to Tiger Cloud. Legacy services and mobile clients were updated to talk to MDS rather than with the database directly, simplifying and speeding up the ingestion process. It also made it easier to update schema and performance characteristics without rippling changes through the entire tech stack.
The end result was excellent. Ingestion is faster than before, costs are lower than before, and we ended up ahead of our original timeline.” Per Grapatin, Vice-President of Engineering at Glooko
Tiger Data Cuts Costs 40%
Once the migration was done, we went back to the metrics and confirmed that Tiger Data did reduce costs compared to our earlier architecture. Storage got cheaper because we were storing less. Compute got cheaper because we could downsize instances more than we expected.
- Compression ratios of ~95%, and some compression ratios as high as 97%.
- 480x faster query speeds, from 4 minutes to half a second.
- More stable ingestion for 100M+ new readings per day across tens of billions of existing records.
While we have finished the core migration from a document database to a unified Postgres platform on AWS, we remain focused on optimization. We plan to move our remaining medical data collections into Tiger Cloud so our high-volume telemetry and clinical datasets can live in one space, providing better performance for patient and provider-facing workloads.