QuestDB

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Overview

I was able to catch up with Nic Hourcard, Co-Founder of QuestDB in this interview to talk about their OSS project & company. After building the time series database as an R&D project for 7 years, the team finally decided that it was time to build a company around it in 2019:

"We started in open source in 2013. Nothing happened. Nobody knew about it. As if it was closed source because there was no community whatsoever...We launched the end of 2019 Apache 2.0 and from there, we began to build.

As for why they wanted to build QuestDB: "the mission of the company...is to democratize this level of performance so anybody can have access to it. Not only the elites in financial services, who have to pay multimillion dollars to get access to that performance."

I hope you enjoy the episode!

-Ben

Episode Transcript

I’ve got Nic from QuestDB with me. QuestDB is an open source time series database in the same as Influx. Nic, do you want to introduce yourself and tell us a little bit more about your project?

It’s great to be here. I’ll give you the two-liner on QuestDB and maybe explain why it’s an interesting and different approach to other time series databases out there. QuestDB is the fastest open source database for time series data and our database is both faster and easier to use for SQL. The idea from day one was, and this started as an R&D project back in 2014, so it was a long time ago. It was to democratize performance and make it available through an open source distribution model and empower developers to solve their problems.

The genesis is that back in the day, this is pre-InfluxDB days, there were no open source solutions to deal with time series efficiently. You had closed source expensive solutions mostly targeted towards financial services and in the open source world, there was pretty much nothing to do with this size of data. That was the idea. Our CTO, Vlad wanted to build something to provide this performance that was previously on yet accessible to a small subset of developers and financial services and make it accessible through SQL so everybody can play with it. That was the mission statement from day one.

This has been more than seven years of R&D and what differentiates us from maybe other players is that this stack is built from scratch 100%. If you go to our GitHub page there are no dependencies whatsoever. The Binary is three megabytes, so it’s super tiny. You can use it in your application, in your data, for example. The great thing is, it’s three megabytes, so there is no external dependency that’s going to add weight to it. Therefore, it’s pretty easy to get started with. I don’t know if now is a good time to give a high-level description of the technology.

{{divider}}‍

I was looking at your repository and it’s got an interesting mix of languages in there. There is some C code, which is unusual to see in a bunch of Javas. I’d be interested to hear about that. Out of interest, though, did this segment come out of high-frequency trading and stock tick data? Is that the birth of it as its own thing?

Absolutely. Our CTO, Vlad, mostly worked in those environments. Low latency trading, mainly at banks, also oil and gas trading companies and it’s true. He initially used some of those techniques and applied them to the codebase and this can be seen in this zero GC Java, for example, which is quite unusual and is typically seen in trading shops and that kind of stuff. That was the birth of QuestBD.

{{divider}}‍

I’m looking at it and you’ve got almost 15% in C and C++ and 83% in Java. Can you talk a little bit about how that hangs together? It’s unusual to see C code associated with a Java project and it was one of the first big deals about Java. You could spawn off a C process if you needed the performance, which back in the day, you did.

Basically, the C++ edition is fairly recent and it’s a high-performance layer to apply SIMD instructions. I don’t know if we want to get into SIMD to explain maybe what it is. It’s fairly niche. If you think of a CPU, there are many cores within a CPU. If you zoom further on a single core, there are multiple execution units. It would be silly to use one at a time and this is what most databases do. The CPU is able to execute multiple things at the same time on the same core. This is what SIMD does, essentially.

In order to leverage this, the data needs to be presented in a certain way, which leads to parallel execution. It’s all about the layout of your data in the first place. We call it basically data that is arranged densely and continuously. That lends itself well to parallelization and sends it instruction. If your data is not contiguous, SIMD cannot be used essentially. If you think about those degrees of parallelization, you have multiple executions within a single core, you have multiple cores and you have multiple servers on top of that so you can go pretty far with that. That’s one of the big differences for QuestDB because of this data layout, and how data can be accessed. We can parallelize things to the maximum.

{{divider}}‍

That’s efficiency that wouldn’t be available to a general purpose database, is that right?

Yeah, exactly. When I say, storing data densely so we store data in arrays. We call these Time Based Arrays and this is unlike B-trees and LSM-trees. This is the typical way of storing data in most time series databases out there. Unlike those databases, we do store data in arrays. One of the reasons this works now is that hardware has advanced over time, and we can now take advantage of it. Years ago, this would not have been possible, because the hardware has evolved significantly. Now, this data structure makes it possible to do things pretty efficiently. SIMD is one example, in that regard. We can extract the most from modern CPUs, whereas in others, you can’t do it.

Also, the data is stored in columns, and partitioned by time. If you need to look for a specific data point back in time, you don’t have to lift the entire table, but you can only lift the specific column and a specific partition. It can be partitioned by one hour. You only lift what you need to look for and this makes it much more efficient and much faster as a result. That’s something else that makes us a little bit different.

The overarching idea, and that’s pretty interesting and tied to a release that we’re going to do. Arrays mean that you can basically achieve pretty solid performance on queries. SIMD is one of those reasons behind it. One might think, “You can have good performance and queries but trees are better to ingest data faster.” That is what people tend to think. We’re here to prove that this is not necessarily true and we have this data structure. You can have super fast queries without impacting ingestion.

This is linked to something called Out of Order Ingestion. If we will not accept and at that point, it is out of order. No timestamp required, which is why the data is so dense. It’s all order by time, by default easily, and you can slice it up, parallelize all of this, and it’s efficient. Sometimes in some use cases in financial services, IoT, the clocks are not in sync, and you’re going to get data out of order. With trees, data arrives out of order, and for each query, it is sorted.

This creates some overheads and this is why it’s a bit slower for queries. This is why we had two options to solve this problem. This is something we worked for quite a long time since our launch, either we change back to trees like everybody else and this enables us to deal with out of order data, but we lose performance on read consistently. That’s what we decided to do. We try to reorder data in memory before it hits the disk. It’s a one-off performance hit.

{{divider}}‍

Is it like when you’re receiving new data, is that right?

It is and this is a pretty heavy operation and we leverage hardware a lot. Maybe years ago, that would not have been possible once again but we’re able to reorder data fast on the fly in memory, commit, and it hits the disk. When it hits the disk, it is ordered. Therefore, we can keep those properties that I talked about before. This is a combination of quite a bit of work and as a result, we’re going to be able to do benchmarks. There’s a template in the industry called The Time Series Benchmarking Suite. We’re going to run those benchmarks because there is an order of data in those benchmarks and it all goes into the same table. We needed this feature in order to do those benchmarks. For us, it’s a pretty big deal and we’re quite excited to see it.

{{divider}}‍

Out of interest, we started using a time series database. I’m afraid to say that it’s not yours. The way that we’re using the datastore doesn’t bother us if the data is out of order because it gets aggregated at the end of the day anyway. Do you know roughly what percentage of use cases the order is important? Is that common or uncommon?

It was common enough that I can work on it. We work with companies that have a lot of sensors in IoT and this is a problem also in services both FinTech and banks. They receive out of order data. It would also be an incomplete solution so it would be such a big trade-off that would harm us in the long-term. That’s why we decided to tackle this.

{{divider}}‍

Before we started recording, Nic told me that he was the non-technical Cofounder. I’m glad that we don’t have your partner Vlad on because I’ll be well out of my depth at this point. Talk to us about how you got started. Were you working together and decided to start a new company? How did that work?

We met at a FinTech company here in London. We started to work on the same project. QuestDB was picked as part of the project. I saw QuestDB run in production and got super interested by this product. I come from financial services, and I dumped a lot of time series data before myself and I was quite excited to prove this hypothesis that we had which was, “Developers need an open source database for time series that is one performant to SQL and open source.” That was the genesis and we got to know each other. There’s also a third cofounder called Tanc, also from financial services, more trading.

We knew time series data emerged from financial services but we saw the opportunity outside financial services. There are so many and we wanted to build QuestDB in order to fulfill those use cases. That’s roughly the story and before that, it’s been an R&D solo project for many years iterating on the tech. Vlad was able to test the database where he worked for some research projects and it’s been tested a lot. It’s stable and there are a lot of unit tests. It’s more than 6,000 at this point. It’s pretty solid so it means we’re able to add new features without breaking up the database. That will help us improve the product as we go.

{{divider}}‍

How did that work from an IP point of view? Is that something that he was working on in his spare time?

Yeah.

{{divider}}‍

Was it a conscious decision to open source the platform or did that feel like a natural path?

It felt like a natural path.

{{divider}}‍

How long ago was this?

We started in open source in 2013. Nothing happened. Nobody knew about it. As if it was closed source because there was no community whatsoever. It was purely an R&D project and people didn’t know about it. We launched the end of 2019 Apache 2.0 and from there, we began to build. We released open source tools before. It’s part of our DNA, so there is this monitoring tool for Tomcat site probe that Vlad open sourced some time ago. It also aligns with the mission of the company, which is to democratize this level of performance so anybody can have access to it. Not only the elites in financial services, who have to pay multimillion dollars to get access to that performance.

{{divider}}‍

That was going to be one of my questions. If you’re selling an esoteric database to a hedge fund, there’s probably a lot of knots on that contract.

Hedge funds tend to do things in-house most of the time. There is the field against buyer mentality. They tend to do it themselves. It’s not a market where we think there is a tremendous upside because they tend to be able to take themselves.

{{divider}}‍

Did you have an idea for a financial model before you open source the project? Did you have some ideas, but you weren’t quite sure where it was going to take you?

We knew that open source is a great way to test the demand and get everything back. It would be a way to know where we stand in terms of product market fit pretty quickly, instead of staying in the dark for many years, and understanding that there is no demand for your new product. Also, we believe that the code needs to be open for critical infrastructure. It’s pretty important like if a database breaks, it’s a big deal so if the code is out there being many eyes on the project to make sure it stays rock solid.

Finally, instead of focusing on sales, you can think of building the product. There was all this community work to do but you can spend a lot more time building the product than otherwise so this is why we decided to do it open source. I won’t lie. We didn’t have everything figured out at the beginning. We learned a lot since 2019 and there are still things that we need to figure out. It’s a complex world and it’s changing everyday.

{{divider}}‍

Do you have any idea whether financial services are the most common user of the platform or have you been surprised by how varied the people using it have been?

We thought that it would be a great fit for financial services and it’s true because there is a lot of market data to deal with and a lot of indicators and series. We are extremely good to deal with multiple series. If you think of a single series together in one single table, we deal with a lot of tables simultaneously well in executing things in parallel. We sell to FinTech companies, banks, and that sort of stuff. Super interestingly, even banks are going open source. You might think that they’re a bit behind the curve, but no. They’re looking ahead and replacing their stack with open source technologies. They are one of those technologies to be open source. It’s like no source available but open source.

{{divider}}‍

Why do you think that distinction is important to them?

There are many reasons but vendor lock-in is one of them. They want to be contributing back to the project. For them, it’s much easier to use these open source licenses. I don’t want to generalize too much and we don’t have QuestDB in production at all the other banks yet, but it seems to go that way. We have great and pleasant surprises in machinery IoT where we have sensors generating billions of measurements per day and we seem to be the only database out there to keep up with this rate.

{{divider}}‍

This is like in industrial settings.

For example, we’ve got this company who’s building CNC machines. I don’t know if you know what a CNC machine is.

{{divider}}‍

Is it big?

Yeah. You’re talking about crap components for cars and they need to monitor some of those characteristics so for example, how fast the spindle rotates RPMs, vibrations of the cooling system, temperature of the lab, and all sorts of stuff. The frequency for each sensor is pretty high and this is nonstop. It’s all day long, over a long time that spans more than 2,000 hours. If you put the debate on hold for three minutes, it’s a problem for them because they’re missing out on critical data and they need to analyze rates. Being able to deal with this ingestion rate has proven to be useful for those companies, so this is an industry 4.0 buzzword. When there are sensors and things to track, we become quite relevant.

{{divider}}‍

Did you know that was a potential strong use case before you open sourced everything?

We felt it could but at the same time, we’re a little bit skeptical. Not skeptical but we didn’t know if IoT was a thing yet. We had to explore it and it looks like it is. We were not sure whether the load of data was that high, if companies were dealing with that much data already or if they plan to do it in the future. It looks like there is a ton of data that companies want to analyze, so not lost in transit like we thought.

{{divider}}‍

It’s interesting as well because when I think of IoT, I think of the Internet of Shit Twitter account, which is hilarious and is a great follow if you don’t mind the swearing aspects of it. What I mean is most people consider it in a retail consumer setting and they probably don’t realize the size of the market that’s so commercial.

You’re right. It’s about to grow tremendously. Machine data is there to grow and that’s why a lot of people are bullish on time series data because this is data that’s coming from machines at the end of the day. If you think that the number of machines and the number of sensors are going to grow, the time series data should grow accordingly in the future.

{{divider}}‍

Are these people deploying stuff, deploying the software in a factory somewhere?

For that specific company, which is in Germany, it’s in the lab. The world is moving to the cloud. There are instances where it’s being deployed on the cloud. It depends. You can run QuestDB pretty much everywhere. We need to build an arm support but otherwise, it’s one binary that you can use pretty much everywhere. We haven’t built a fully manifested solution. DB as a service, as we call it, so that’s part of the roadmap.

{{divider}}‍

Is that something you’re working on?

Not right now but it’s something that we’re going to be working on.

{{divider}}‍

How much of what you were talking about with regards to low-level CPU instructions are applicable to ARM chips?

We temporarily pose ARM support because it was extremely hard to apply. It’s not extremely hard, but a lot of maintenance and extra work to make it work on ARM, so it’s possible but it requires a bit of work. So far, the demand has not been extreme. That’s why we put it aside and a lot of issues are appearing on GitHub asking for that support, so it’s also something we need to think about pretty soon.

{{divider}}‍

There are multiple revisions of ARM architectures as well. Am I right in saying that they move more quickly than the AMD 64, which is much more set in stone? Is that fair to say? Is ARM more of a moving target?

This might be more of a Vlad question. Too much in detail here but yes, it’s roughly high level.

{{divider}}‍

How was the experience of launching it on GitHub? Did you have expectations prior to that or hopes and dreams?

You hope that it’s going to be amazing. You put it out and nobody notices. That’s been the first month or so. Friends and family liking and starring the project. The first step was to basically increase awareness from 0 to 1. We decided to talk about tech. Our tech is fairly novel, an approach and we build everything so there is a lot to talk about. Our approach was, “Let’s write a nice article. It’s quite technical that goes through some of the design choices, and etc.”

SIMD was one of those articles and let’s put it out there and see the reaction. We put it on Reddit and Hacker News. That’s when things started to happen for us. It’s a big reaction, a lot of comments, and a fairly good reception. Sometimes, it’s hard to put something on Reddit, because people are going to be critical but for us, it was pretty good. People were intrigued, “How do you do, Java?” “It’s the same but that’s exciting. Not many databases have it. How did you do it?” That’s how we got started. Those things are picked up by publications, re-shared, and etc. That got us quite far.

By doing those technical articles and sharing them, that got us from 0 to 0.1, so to speak. That was the first thing we did and once people came into our Slack, that was the effect. We had a Slack channel that was totally empty. The Cofounders were there. Since day one, we share everything on Slack. That’s been one of the things we were quite proud of. As if it serves live but it’s available for people to see. You share with the community what you’re working on every day.

If there are difficulties, you share those. Every milestone, you talk about it, and people started to come and we built a community from there. That’s by engaging with those people. YC tells you one thing, “Do things that don’t scale to start with,” and that’s exactly what we did. We had one to one conversation with everybody joining and we got to know them well and this was extremely powerful. You cannot do that now.

We could still try to keep up but it’s pretty hard with a lot of people joining. We welcome them and we do what we can to understand where they’re from, what the problems are, etc. In the beginning, it was a bit easier to do and it’s when you start to understand why people come to you. What triggered them? What problems did they face with maybe other alternatives? This helps you to comprehend much better the dynamics in the space. Also, it helps you shape your messaging so as to re-appeal to those developers who need your solution the most.

{{divider}}‍

Do you think that asynchronous communication messaging mechanism like Slack was instrumental in that? Do you think you couldn’t have got that information from a web form, Discourse forum, GitHub, or something like that?

GitHub is great. We have a lot of issues there and there is communication but it’s taking things to the next level and you can engage at a much deeper level with developers coming your way and understanding them. I would think it’s been one of the reasons that we managed to start building this community so well.

{{divider}}‍

Does it add a bit of pressure? You guys are both in London. Does it worry you if someone’s in Adelaide, and they ask you a question at 3:00 AM on a Sunday and there’s no one there? Is that a concern? At the start, if you don’t have a community of people around the world, then they’re going to not get a reply for quite a while.

You’re correct. We managed to be responsive. We did our best to be as responsive as possible but it’s true. Sometimes at 3:00 AM or 4:00 AM, it was not possible. It means that we stayed up until 5:00 AM and because it kept going until super late and we had to be there. On those occasions, we were around but most of the time, if there’s a question on the board, we come back to it in the morning but still, the community appreciates that. We were not even paid at the time. We didn’t raise money. No salary whatsoever. We’re trying to put things together so they know that and that they don’t mind waiting for a few hours.

{{divider}}‍

That makes a huge difference. You’re always going to get some people who expect free support but it depends. If you’ve raised $100 million, then it changes the context of that conversation maybe. I still think you maybe shouldn’t give free support if people are aware that you’re doing this for the love of it.

There are ways to increase the engagement from those developers and make them feel they’re part of the community. Getting to know them is one thing, but then give them a voice. Put together webinars, collect their feedback, understand what they need. Developers are quite vocal on average about what they find about the product and what they would like to see. Triggering those discussions was effective for us and the great thing is when people love the product, they also want to make sure people know about it. We did a webinar with some of our users in Prague. They share their experience on why it’s great. Other people ask questions on how do you deploy it, what’s the best setup and there’s that discussion going. This is great because there is this word of mouth effect where you don’t need to do any marketing whatsoever.

It’s people talking about your product to the people they know. That can go pretty far. People will eventually want to contribute in different ways. They want to write a blog post. They’ve tried something that works and that you’ve not done yourself, because we know that the time and here we go. They put it together, they want to write about it and off you go. It’s on the tutorial page, so things like that helped. I’m sure you’ve heard of swag initiatives. That is a great way to reward developers who put a lot of time and effort into making the product better, so we did that as well.

{{divider}}‍

We’ve had conversations that have gone on for too long trying to come up with some interesting swag that’s not a hoodie or sticker that might be interesting for people. We need to do something about that. Having said that, I interviewed Paul Dix from Influx. He was one of the first people on the show. They sent me a hoodie and it’s comfortable, I have to say. I’ve started wearing it because it is comfortable. Maybe hoodies are fine.

We’ll send you a hoodie then.

{{divider}}‍

I get my family to be the judge of who’s got the softer fleece. One thing I’m interested in is, were you hoping for the Slack channel to get to a self-sustaining point where it wouldn’t necessarily be people working at the company to help out? Is that possible? Is there a critical mass point where you get this chain reaction of people helping each other?

It happens. We have seen that on many occasions. It’s somebody asking, “I’ve got this IoT use case. How do I run it?” We’re ready to answer your question and somebody else said, “I’ve been using QuestDB. It’s great. That’s my setup.” A lot of other people joined and that was great to see, especially for the first time.

{{divider}}‍

That must have been an amazing moment because if you’re asking questions for a product and someone else who’s a customer of the product is giving you answers and it’s not the person who is responsible for the product, you’re getting a completely unfiltered opinion.

Exactly and that was great. It doesn’t happen, all the time. Maybe for this to happen on a continuous basis we need a community of 10,000 plus developers and we’re not there yet. We still need to drive this but it’s nice to see. I don’t know if there is a secret sauce there. It’s happened for us. What makes it different is those guys were compelled to contribute. They like the products and they want to make sure that other people get started with Quest and have the same experience that they’re having. Maybe it’s a byproduct of them loving your product. That’s the YC thing.

{{divider}}‍

I was thinking about it. Those are things in my head that make things that people love. It all boils down to that, but you’re leveraging that in an interesting direction.

We still do things that are not scalable. We help people a lot. Sometimes they don’t pay for support yet. We put a lot of hours but it’s important and I’ll give you an example of one proud user who told me, “Initially, you guys were so responsive.” When I wanted to put this in Prague, it was amazing. The experience was incredible and I managed to migrate from InfluxDB in 40 minutes. It was working great and I understand that this is not something that can go on forever. Therefore, because I felt what it was to get that support and how good it was, I’m ready to pay for it in the future. If you show developers what you can do, then they should be willing to pay for it in the future because they are aware. You cannot be something that stays for free forever. Otherwise, you cannot scale. The first was great to hear.

{{divider}}‍

That’s been a recurring theme talking to people who’ve started companies around open source products. There seems to have been a shift in perception from developers in general around exactly that it being okay to be asking for money or making decisions around what’s open and what’s closed. I loved RethinkDB. I was a huge fan of RethinkDB when I was working in a software agency that I’d started ages ago. We were recommending it. It was gutted when they had to close down. It was a bad look for me as well because there were clients that I had who were running it in production and all of a sudden, it was like, “Oh my God.” They got to the point where they got some critical mass around the product. It had enough momentum behind it. I haven’t checked into it for a while in terms of that.

It’s maintained by recommendations and stuff, so it’s going on. It’s Renaissance.

{{divider}}‍

Maybe some of my old clients are in there trying to help it along. That’s been interesting. Everyone seems to have the same experience at least in the vast majority of their community are totally respectful of the fact that it’s a commercial entity, and you need to be able to eat and live. There’s nothing wrong with that. Tell me what the story is. What happened in terms of you guys raising some money after you open source the project?

At that point, it was storytelling to VCs there was not much going on. We started to get a bit of traction and avenues. We appeared on DB-Engines Ranking out of the blue. It was like, “Wow.” That’s possible, so that was quite exciting but beyond that, there was not much. There was one proud instance that the place worked before but there was it. It was a leap of faith from that fund but that’s their business. They got to take their chances and after that, we did YC, so it’s slightly unconventional, in a way, but it was quick in succession more or less. That summer of 2020. YC gave us a small amount of cash. As we know, it’s a standard deal thing. So far, that’s been the capital we received.

{{divider}}‍

People in Y-Combinator must be seeing a much larger proportion of their cohorts based around open source projects now.

It’s exploding. There is a guy called Joseph Jax.

{{divider}}‍

We interviewed him for the show.

He tracks that stuff. There is a link, you see for all the open source companies per batch over time. The last two batches have been exploding. The end of the story is during the bachelors doing those group office hours so it’s five other companies you’re assigned to. You talk about your challenges and etc. We were in the Developer’s Tool category and there was a lot of emphasis on sales. At first, it was not applicable because we’re building the community.

There were no sales to do whatsoever. It was a different type of focus. We had the idea to start this way OSS Initiative to basically do those group office hours, but focus on open source. Since it’s been a great success, we have 85 YC and OSS Founders already. They’re active and we managed to bring good and successful founders in one-to-one interviews. I even spoke with the Influx Cofounder, Todd. It was great to hear those insights because they’ve done it all and there is a lot they can share with the next generation, so to speak.

{{divider}}‍

Did you ask him for a hoodie?

No. He’s not in Influx anymore. He doesn’t have access to those hoodies now. That’s been great. We’re looking forward to seeing more founders joining but that’s where we learn the most because those are so specific. There are things that are changing fast like licensing, what you can monetize, and etc. It’s great to get the perspective of people with so much experience. It’s been pretty cool and that was another example of building a community even though with the YC badge, things happen a little bit faster and easier but it’s been great.

{{divider}}‍

From what I’ve read, though, it’s not that unusual raising money, and going and doing YC.

It happened quickly, so we announced the round after we joined YC, which is all in one go. It was more or less at the same time. After joining, some have already raised before and other people raise after Demo Day. The way they put together a Demo Day is smart because it creates a lot of tension around this event. Investors know that if they wait after Demo Day, there is going to be so much interest in so many investors willing to invest or at least interested in the company. It’s going to be pretty hard for them to write the check, so you can also use that to your advantage to complete a round successfully. That’s effective and it was virtual for the first time.

It was a bit weird at first 1,000 people. You see the number below and you don’t see them. It’s weird. They did a great job, though. You do your pitch on the Slack channel every time there is an interest inbound from an investor. If they like what they see, they press like and they get an email. There was a Slack channel with thumbs up every time there was one of those likes. You do your pitch, and you see those thumbs up going down and that gives you a bit of a beat. It’s cool. They might do things like that.

{{divider}}‍

It’s like Pavlov’s YC. What’s next for what’s next for QuestDB? You’ve talked a lot about building the community and you’re going to start working on going to market soon.

What’s next is on the product side. We need to ship this out of order, which has been in the works for a long time and that’s the combination of so much work and also the proof that the approach works. For us, it’s important and there is replication after high availability.

{{divider}}‍

It’s two pretty trivial features.

That takes a few days.

{{divider}}‍

Wait for the pull request from someone.

Can you guys help us out? Once this is done, we can focus on building the cloud offering. That’s going to be the big one. That’s the main segue towards monetization for us. There are support contracts you can put in place now and that is great to get initial revenue. If you want to scale that, the Cloud is the offering to have. We hear of many companies transitioning to the Cloud and some of our users who are not doing things on the Cloud, they want our SaaS offering. We know that the demand requires a lot of resources and also time. We need to hire people to help us build this. It’s going to take several months, for sure.

{{divider}}‍

Definitely hiring, company culture, and all that stuff in COVID time are definitely not knowing someone and working with them is pretty tough. There’s been a lot of talk around remote-only companies, but a lot of those get a massive amount of meetings up once every six months or in some Hawaiian island or something. Everyone’s in the same boat pretty much apart from Israel who now vaccinated everybody.

It’s tough. I’m not going to lie, especially at the beginning. Few people in the same room, there is that magic happening. If not in the same room, it’s much harder and therefore, you have to find new ways to make it work. We have simple things. It’s trivial but that works, so every morning, there’s a call, everybody joins. What we’re up to? What we’re going to do? This is not decentralized. This we don’t share with the community, though.

{{divider}}‍

We’re the same. We have two of the guys are in the valley. They get up mega early, Greg and Alex. I couldn’t do that every day. We have 30 minutes to 1 hour where we figure out what we’re going to do.

We will do another one late afternoon to see how the day went. It’s not to say, “You didn’t do a good job.” How bad is that? It’s more to show that days can go wrong especially in our case, where we’re trying to build something a bit new and innovative. Some days go to shit. On some days it’s not working. You need to do it again. It’s nice and a way to connect and talk about the weather in London.

{{divider}}‍

Finally, I got on the bike. My brain has forgotten what endorphins are.

It sounds weird. You’re not used to it anymore. It’s little things like this. It’s not rocket science. It’s making sure you’re in touch with your team and more frequent one-to-ones to check in because it’s hard. It’s hard on everybody but when you’re building something, it’s all that is there. When there is excitement and when there is the goal to ship this big release and people are moving in the same direction, that helps to keep spirits high.

{{divider}}‍

I’m going to wrap things up. If you’ve got anyone, any URLs or contributions that you want to give a thank you to.

All of our contributors. There are many and they’re all on our GitHub page, so we thank them there individually. Find us on QuestDB on GitHub and http://QuestDB.io . Everything is there. We have a tutorial page and we have great contributors there too, how to set up Quest DB for financial market, IoT, to make it work through PostgreSQL wire, etc. We’re going to have a community page soon. That’s going to be a little bit more structured. Developers will get more clarity about what contribution leads to what swag, etc., to roll this out.

{{divider}}‍

Nic, thanks for your time. It’s super interesting to hear your story so far.

Thanks to you, Ben.

{{divider}}‍

Take care.