We're looking for writers to create articles for our blog. Have you had success with QuestDB? Do you know time-series data, time-series visualizations, database internals and ecosystems, or have a neat distributed database story to share? If so, now is the Write Time!
The opportunity is paid. We'll support you along the way with guidance and editing, and then we'll publish your work on our growing blog. Afterwards, we'll share throughout our social network. It'll help build a portfolio, expand yourself as a voice in the community, raise awareness of your projects or tools, and improve your skills.
Intrigued? Read on!
What we're after
Our team cares deeply about our content. We've had many Hacker News frontpages, top-of-sub-Reddit appearances, and incorporation into many popular newsletters such as This Week in Rust and more.
We know that many talented engineers, data scientists, technical writers, and/or general technologists want to increase their exposure, improve their writing skills and share their expert knowledge with the community. But many are missing a platform and some support to help them do so.
To help facilitate this, the QuestDB blog and editorial team welcomes your next technical tutorial, deep dive, research piece, or whatever else you're cooking.
Articles of interest will include the following technical topics:
- interesting things built with QuestDB
- use-case deep dives into core subjects, specifically finance and IoT
- time-series databases, including performance benchmarks and comparatives
- cool analyses and manipulations of time-series data
- time-series visualizations via our native Grafana plugin
- interactions with powerful 3rd-party tools and ecosystems (AI, ML, and so on)
The works must be unique and created in tandem with the QuestDB team. Naturally, we expect them to relate to QuestDB. Ideal length is typically between 1250-1750 words, but it can be as long as needed to tell the story well. We write in markdown, and appreciate a blend of images, diagrams and sample code, as well as prose. Balance is key to maintain readability in a content-satured world.
As for style, it's important to us that we maintain your unique voice and character. Generally, our blogs are natural and conversational, with an emphasis on technical accuracy and depth. Our audience is highly astute, and so we like to push the technical boundary whenever possible.
But before we go any further... LLMs are an elephant in the room. Our position is that we appreciate them as co-pilots. But the words must be your own. We have several methods of testing for LLM-generated content. We've also gotten fairly keen at spotting an LLM's lack of natural cohesiveness. But that said... We trust your method, and we'll trust you.
What's in it for you
We'll pay $500 for each article that we publish. We'll credit you in full, and we're happy to include personal social links and mention you during our community outreach efforts. And of course, we'll send you some crisp QuestDB swag.
If you'd like to cross-post your works to other mediums, we welcome that, too. The requirement for this is that we set a canonical URL back to the QuestDB website. But we're flexible, and happy to hear your ideas.
In addition, you'll work with a very technical team and an experienced editor. If you're looking to grow as a writer or to add to your portfolio, then this is a solid opportunity.
How to get started
There's a few steps on the road to publishing your content.
1. Pitching
First, we'd like to see a "pitch" for the idea. Email it to us at write-time@questdb.io. Once received, we'll review it and get back to you in a timely manner.
While we are willing to work with authors of all skill level, please note that we will not accept every proposal. We might provide a counter-proposal based on any of your prior works or experience that we feel may be a better fit for our audience. Or, we may politely decline.
A template may look as such:
- Topic
- Audience
- Tools used
- Summary
For example:
- Topic: Building a death ray with QuestDB
- Audience: evil geniuses, aspiring evil geniuses, and those who love them
- Tools used: QuestDB, Python, and a dash of evil
- Summary: Building a reliable death ray is hard work. You need top time-series performance. We'll use the QuestDB Python client to ingest billions of data points from our field of quantum gravity arrays. And then, once ingested, we'll perform very fast (and very evil) queries to maximize the face-melting heat-death throughput of our physical ray. Please note: we are not liable for any outcomes from following this tutorial.
Or something like that. Of course, the topics are broad. Financial data, sensor data, are two very common cases. If you're comfortable in either, consider starting there. But we're open to your ideas.
Another template may be:
- Topic: Optimizing high-performance sensors with QuestDB and Python
- Audience: IoT firms, database performance enthusiasts, Pythonistas
- Tools used: QuestDB, Python, Raspberry Pi
- Summary: Sensors come in many shapes and sizes, and their hardware profiles can vary. We'll take a Raspberry Pi and take a deep dive into QuestDB configurations and settings to find the optimal performance profile. We'll balance various settings like deduplication, out-of-order indexing, and more, as we try find the maxima of performance and utility.
2. Drafting
Once we approve the pitch, we'll recommend a "draft template".
For the drafting process, the ideal structure might be:
- Engaging, attention-grabbing introduction
- Broad idea 1
- Supporting point/image/diagram/code a
- Supporting point/image/diagram/code b
- Supporting point/image/diagram/code c
- Broad idea 2
- Supporting point/image/diagram/code a
- Supporting point/image/diagram/code b
- Supporting point/image/diagram/code c
- Broad idea 3
- Supporting point/image/diagram/code a
- Supporting point/image/diagram/code b
- Supporting point/image/diagram/code c
- Conclusion
While creativity in structure is welcome, we emphasize the need for precise and accurate technical details in any QuestDB content. At this stage, we're at "rough draft". Our diagrams might be on a napkin and our paragraphs may be huge. But somewhere within lies a diamond.
3. Editing
After we've received your draft, collaborative editing with the QuestDB team begins. We'll help shape and groom your work over a few rounds of back-and-forth, all while preserving the essential spirit of the work. This may happen through a Google doc or a pull request, or something similar. The team is adept at giving graceful, accessible and conscientious feedback.
We strive to keep the process light, productive and fun.
4. Publishing
Boom! Editing is done. The work is complete. Now, some brass tacks. The article for all legal intents and purposes is owned by QuestDB. We'll ask you to affirm a common agreement to that effect, transferring ownership and waiving liabilities and such things.
After that, we'll send you your well-earned cash and swag. Then finally, we'll publish on our blog and share it in our social channels. Depending on the audience, we may also broadcast to Hacker News or Reddit, newsletters, and similar.
Inspiration
A few examples may help demonstrate what we're after:
- (Deep dive) The Billion Row Challenge (1BRC) - Step-by-step from 71s to 1.7s by Marko Topolnik
- (Tutorial) Ingesting financial tick data using a time-series database by Yitaek Hwang
- (Tutorial) How to increase Grafana refresh rate frequency by Yitaek Hwang
- (Deep dive) The Inner Workings of Distributed Databases by Alex Pelagenko
For the full list, see the QuestDB blog.
Summary, right place, write time
If you've got a technical story to share, we want to help. QuestDB is the fastest growing time-series database, and we want to put your work in-front our sharp, professional community. Technical depth is key, and so is your character.
If you're interested, please reach out to us at write-time@questdb.io. If you want to talk about it more, feel welcome within our public Slack and give us a message. We'll work with you there.