Picking up QuestDB today and try and evaluate if it’s going to work my company’s time series needs. I’ve run into a blocker that I can’t tell if it’s a bug, or just my lack of understanding of some of the built in functions. Where would the best place to go get ask that type of question?

Hi welcome to QuestDB! Please share more details here and our team will get back to you asap (most of the team is based in Europe.) Please let us know your use case and the particular problem you have encountered.

I’ll hopefully be able to explain along with the attached images. My goal was to essentially “fill” empty hours from my first query with 0s by joining my first query with a generated sequence of timestamps. But when I join the two queries, I get really weird behavior. The two major issues… 1. The generated sequence of timestamps now seems to have changed and is stepping in twice the size. 2. The joined values are just straight up different in the results table.

[Bolek has provided the correct reply so deleting this one 🙂 ]

@Sean Callahan Try this :

with aggData as (
select timestamp_floor('h', timestamp) as hour, sum(count) as requests_per_hour from api_usage where timestamp >= dateadd('d', -1, timestamp_floor('d', now()))
group by hour 
order by hour
), series as (
select dateadd('h', -25+x::int, timestamp_floor('d', now()))  as ts from long_sequence(24)
)
select * from series s left join aggData a on s.ts = a.hour;

I think the issue here is that timestamp_sequence is not materialized so it should only be used to fill tables with data in simple queries . See https://questdb.io/docs/reference/function/random-value-generator#usage .

Ahh I see. This is great. Going to put this in the back pocket for future use. Thanks!

Hi @Sean Callahan what are your first impressions of QuestDB? smooth enough, or are there things we could do better?

So far so good. Been a little tricky picking up some of the custom SQL for QuestDB, but I’m getting there. If I had any feedback / follow up questions, these have been on my mind. 1. When using QuestDB Cloud, how does auth work for the read / write clients? The docs are a bit confusing on this front. 2. Sometimes the error messaging in the console is not as useful as I would hope.

Thanks Sean! We have Basic Auth for the web console and are bringing Authorization for the read/write clients (fine-grained column permissions via SQL) in about a month or so. You can stay up to date with our roadmap here: https://github.com/orgs/questdb/projects/1/views/5 Could you kindly give us a few examples about the error messages you had in the web console? thanks!

I’ll see if I can track down some of those errors. One thing I don’t quite understand with QuestDB, specifically cloud… If I deploy a cloud instance, and start writing to it, is there anything that prevents bad actors for talking to my instance?

@Sean Callahan we have TLS across all protocols, auth is configured by default for all 3 endpoints (http/pgwire/ilp) and IP whitelisting is supported

Hey Sean, just for context, the model of having a DB server exposed publicly but protected via TLS and auth is very common. For example Amazon RDS (managed relational databases, like postgresql, mysql, oracle…), Amazon ElastiCache (managed redis), or Amazon OpenSearch (managed elasticsearch) offer that option.