Back to blog
3 min read
Apr 08, 2026
Table of contents
01 What this is02 What I'm looking for03 How it works04 Why I'm doing this05 How to get involvedThere's a lot of good technical work happening with TimescaleDB that nobody ever writes about. Not the big enterprise case studies on our website (those come from paying customers with a whole customer success process behind them). I mean the developer who built a sensor pipeline for their homelab, the solo engineer who replaced InfluxDB at a startup and never looked back, the team at a small shop running operational analytics on live Postgres data and wondering why they didn't do it sooner.
I encounter amazing builders every day as Community Manager here at Tiger Data. I know those stories are out there. I want to find them and tell them.
The Community Member Spotlight is a new case study series featuring real projects built on open source TimescaleDB, published on the Tiger Data case studies page, newsletter, and social channels.
Here's how it works: you fill out a short form with 8 questions about your project. I may follow up with a question or two if there's something worth getting into. Then I write it up, send you a draft to review, and publish it. Final pieces don’t go live without you signing off first.
Everyone who's selected gets free Tiger Data swag! And this one is for the open source folks only, no Tiger Cloud requirement, no paid relationship needed. If you built something real with TimescaleDB and have a good data story, you're eligible.
The use case matters less than the story behind it. I'm looking for projects where there's something technically interesting to say: a real problem, a real solution, and some evidence it worked (ideally with an architecture diagram or figures to prove it).
A few examples of the kind of stories I'd love to highlight:
The before/after. Queries that took 10 seconds now run in 200ms after setting up continuous aggregates. What did the setup look like before? What changed?
The architecture decision. You were evaluating InfluxDB, looked at the trade-offs, and decided to stay in the Postgres ecosystem. Why? What made TimescaleDB the right fit?
The thing that wouldn't have been possible otherwise. An IoT pipeline ingesting sensor readings from 500 devices at 10-second intervals, with 3 years of history online without breaking the bank. How did you get there?
The unexpected use case. If you're using TimescaleDB for something we'd raise an eyebrow at (agentic workflows, ML training pipelines, operational event stores), I especially want to hear from you.
Good stories come from all kinds of projects: solo dev side projects, small team products, internal tooling at startups, academic research, open source infrastructure.
The process is pretty lightweight:
Once it's live, I'll coordinate swag with the events team.
Part of it is simple: I love open source software. The whole point of OSS is that people build things and share them so others can learn and build on top of it. That sharing is what makes the ecosystem work. But it only works if the knowledge actually gets out of people's heads and into somewhere findable.
Enterprise case studies are great for social proof, but they only tell part of the story. Some of the most interesting work happening with TimescaleDB right now is by individual developers and small teams who figured it out themselves, built something that works, and moved on. That knowledge doesn't get documented anywhere useful. It stays in someone's head or a private Slack channel.
Every spotlight we publish becomes a reference for someone else hitting the same problem. I also flag the strongest stories to the broader marketing team so they can see what people are actually building, and the best ones get picked up for longer-form case studies.
I'll be reaching out through the community Slack, GitHub, Reddit, Stack Overflow, and to people mentioning TimescaleDB on LinkedIn and X. But honestly, filling out the form yourself is the fastest path to get my attention.
If you've been thinking "I should write up what I built," this is your opening. Fill out the form, I do the writing, you review it, and your project gets published with your name on it!
Any questions, DM me in the community Slack.
Yes, You Can Do Hybrid Search in Postgres (And You Probably Should)
Most search stacks run four systems to answer one question. You don't need any of them. Build production hybrid search in Postgres with pg_textsearch for BM25, pgvectorscale for vector similarity, and Reciprocal Rank Fusion to combine them. One query. One database.
Read more
Receive the latest technical articles and release notes in your inbox.
