Subscribe
Share
Share
Embed
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Roi: I wouldn't want to program in any other language. But see, I, I just like the simplicity of the language. I don't like, uh, the fancy interfaces and I don't like, you know, things being hidden from me.
Corey: So, Pirate's favorite language. Some people think it might be R but, uh, Pirate's First Love is the c.
The dad jokes, do not get better from here.
Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Roi Lipman, who is the CTO at Falco db.
Roi: This episode is sponsored in part
by
Corey: my day Job Duck Bill. Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles of.
Phone number, but nobody seems to quite know why that is. To learn more, visit duck bill hq.com. Remember, you can't duck the duck bill. Bill, which my CEO reliably informs me is absolutely
Roi: not our slogan.
Corey: Chloe, thank you for joining me. Thank you, co. Happy to be here. So let's start at the very beginning. Uh, it seems like you can't swing a dead cat these days without hitting a different kind of database in all shapes, sizes, levels of management, et cetera.
What, what type of databases, alco, where does it start? Where does it stop?
Roi: I think, um, over the years there, there was an explosion of different, uh, databases coming. Uh, to the market. Faculty b is a player in the graph database field. Um, one of many. Um, you can usually, you know, there are the relational databases, which everybody probably know.
And then about maybe a decade or two ago, um, we started to see no SQL databases such as Redis Key Value Store. Um, of their type. And within this NoSQL category, you can find document, uh, document databases such as, uh, Mongo, you see time series databases. Today you would also find vector databases. And there's this niche, um, which is the, you know, graph database field, uh, which we've been in.
For the past 10 years now,
Corey: I'm reminded of Forrest Brazil's comic years ago before he joined Google. Uh, sort of disambiguating all of the different. AWS managed database services. 'cause it really seemed for a little while there, like the DBA job of the future was gonna be figuring out which of their 40 databases was the right option for any given workload And for, uh, the Neptune option that they offered.
The, uh, the flow chart decision was, do you need, uh, graph database? And the only option was No, you don't. And it led right back to the previous question, which I thought was. Pretty amusing. Uh, it seems these days that graph databases have found a niche, but, but it is a niche. It's, it's a, it's, I've not built anything on top of one yet.
And I talking to other folks, I don't think I'm very alone in that. Am I, am I the freak?
Roi: No, I don't think so. I think that, uh, it's very natural for, to, for people to think. In tables. Well, it comes very natural to say, oh, my data fits into a table, so I'm gonna go with relational, uh, database. Um, those who are aware of this entity called Graph, uh, these are either, um, people who have encountered this probably during their time.
At the university
Corey: or working at Facebook
Roi: or, yeah, I mean, if they think about, you know, how uh, the data in Facebook is modeled then, or in other, in any other social network, you would see this shape of a network or more generally We like to call it a graph forms, so, um. Apparently, uh, or as it, as it turns out, there is this very famous saying, uh, everything is a graph.
So even if you are aware of it or not, um, it's very likely that a lot of domains are behind the scene or can be relatively easy described as a graph. Just, just throwing out a few examples. A social network obviously is a graph, roads and intersections, maps. These are graphs. Any type of, um, uh, network where data flows is, is a graph.
Um, so graph do pop up, uh, in a lot of use cases. It's, it's just, uh, the. You know, the way in which we're viewing the problem and realizing that, oh, uh, I'm dealing with a graph here. So maybe instead of trying to false a graph structure into a different, uh, data model, such as the document store or a relational database with tables, maybe I should use the right data model for my domain.
Or for my problem. And just to, to wrap this up, think about a navigation system. The one that you might have in your car whenever somebody changes, uh, the map. Let's say a new road was added, or uh, some road was removed because there's some construction and then the road is closed. Every update to that map need to go through a validation that says, uh, for example, in a given, if in a given state or in a given country, you should be able to drive from every location to any other location on that map or within that state.
Corey: That is definition of how roads should work.
Roi: Yeah. And it's pretty obvious. I mean, you should get from point A to point B. Try to solve this problem or make this verification when modeling this data as a table or as a set of tables or a set of documents, it's practically impossible. You need, you need a graph.
It's a, it's a graph problem to begin with. And so, yes, I think that graphs are still a niche, but they do, uh, with. The explosion of ai, we do see them coming back. Real strong with this idea of knowledge graphs.
Corey: For a while my default go-to was DynamoDB, and that was great for a variety of reasons for small throwaway projects, but something you learn pretty quickly when you start reaching for, uh, the every, uh.
Every, every, you know, the tool you have is a hammer. Every problem looks like your thumb. Uh, when you're using Dynamo, it works really well. If and only if you know exactly what your access patterns are going to look like in advance. As soon as you start changing that due to evolving requirements, suddenly you're in a world of pain because you get to reimagine your entire table model, redo a bunch of stuff, possibly do a migration.
So I have found that reaching by default for something like Postgre squeal tends to be the right answer for a lot of these things. But also increasingly I find that I don't care what database it uses 'cause I'm not the one building the code. I am hurling it over the wall for an AI tool to wind up building out for me.
Uh, how are you seeing, I guess, the rise of graph in that universe?
Roi: In the universe of. People building applications with ai,
Corey: throwing it over the wall to AI so that it just decides whatever it's going to build. I, it has preferences and in some cases I've switched providers just because I got tired of fighting against it.
Like, no use Amplify, don't want, I want to use Versal Fine. Use Versal. Just stop bothering me with it.
Roi: I personally, personally, try to avoid handing off my work, uh, to ai. So I use it mostly for. Doing code review. So I, I don't have enough experience to to, to answer that question. I, I'm not in the position where I constantly hand up handing off, handing off work to an ai.
So
Corey: Right. In fairness, that's, that is where most developers are. I have the advantage of being a different kind of developer where my only two languages I know are brute force and enthusiasm. When I want a line of business app to glue two things together, well, that would've been a multi-day undertaking previously, and now it's, eh, just.
There'll be a clicky thing so I can stop copying and pasting between two things like I have for four years. It's, it's basically the glue applications between things. And historically I found that I cared a lot more about things like data structures, the underlying code, how this stuff all ties together.
Increasingly, I find as long as I have a solid test harness, I can, I don't have to care as much. Now, will this have problems if I start scaling any of these things? Oh, absolutely. But that's not a, that's not a risk for the way that I am building a lot of these things to begin with. It's more or less building everything with the idea from the outset that it's probably not gonna work and I'll throw it away and replace it in two months with something else, which is frankly, a luxury.
But I do find that it gets me experimenting with different technologies I otherwise would not have. Had the ramp up time or focus to dive, really dive into, have you seen, have you seen folks that is coming to Falco from, well, AI suggested it, so now I'm curious, or is that not really the, the path that leads folks to a graph database?
Roi: The way that our prospects of customers are ending up using Falco D Beta are usually two main paths. It's either they realize that they need a graph and they, they do a quick, uh, search. And they, uh, come up with a, a number of contends and, uh, hopefully they would pick a faculty. So those are sometimes they, they are, uh, coming fresh to this type of database.
They did not have experience before, but they understand that the problem that they're trying to solve is best or is suited for a graph database. That's one path. The other one is, uh, prospects who had some experience with the grab database, maybe a short while or even for a few years. Um, and for any, you know, there might be multiple reasons that they're not happy with their current provider.
Um, and so they, they want to try something else, usually. Uh, those people who are turning to fle DB are turning in, uh, because they have concerns regard to either scaling or performance. So this is where fle DB shines. Um, when you try to compare it to the other vendors, um, we have a unique approach to how we go about representing graphs and traversing them.
But we also make it extremely easy for you to scale out, uh, in case you have multiple tenants or multiple graphs that you want to host. On your, uh, Falco DB database.
Corey: Something that I, I noticed about Falco that ties into, I guess, a preexisting bias I've had because for a number of years it seems that folks have been pushing really hard to make Vector Search a its own database type, but it, it's become pretty clear across the board, across these are the database types that I spend more time with.
That vector search is a feature, it is not an engine itself, and it appears that. Falcor has, Falco DB has taken this in a similar direction where you, you obviously have done a fair bit of enrichment with, uh, your own graph rag stuff, but vector search is a, is a already a feature that Falco DB does. Where do you land on that
Roi: vector search or semantic search is, um, really.
Important type of search that you, you can perform at the very beginning, or at least this is how I remember things a few years back with the, with the, with the ability to compute, embeddings and then search, given some data point, which you also turn into a, a, a vector, and then you search through the, the vector space.
Uh, the first product that came out were actually vector databases. Companies such as Pine Cone, wate, I think Quadrant, and there, there are plenty. Um, and eventually the other players, relational databases of databases, any type of database looked at it as if. I don't think I want this feature. I want the ability to perform semantic search over my own, you know, data.
I don't need a, a, a new database to add to the stack and manage. I look at it as a, as a search capability. And we already have indices doing full text, doing exact match. Why not doing also, uh, geo. Why not ex extend the index capability with, with Symantec? And this is what the entire industry had done. You would see these days, um, throughout the spectrum, almost any, any database would now support, uh, a vector capability.
Now, I'm not saying that there's no no room for vector databases out there. I mean, if you are hosting. Uh, hundreds of, of millions or, uh, or even more vectors and that's, you know, the only type of information that you are storing for your application, then yeah, the vector database, you know, might make sense.
Um, but. If your numbers are relatively, you know, reasonable, and you need those vectors just to do semantic search over the broader, uh, data set that you have. Uh, for example, let's say you have a, a database containing users and every user has a profile. Image and then you are getting a new image and you want to see, you know, which the top five users that are, you know, they look like the, the given query image.
Then okay, use, use a vector index capability. So that's what we've done. This is what the entire industry had done. That, that I think, put a question mark on whether or not do we really need vector databases. I think that for the extreme cases, yes, but for the majority you would see people are using Postgres and they're doing TAL cells within Postgres.
Others are doing it within file cord tb because you know, they have a graph and then they, they want this semantic capability.
Corey: Which tracks, I mean, I'm not here to crop on other people's use cases. It's, it's one of those areas where people get very sensitive about it. It's like they're children. It's like, oh, so which is your favorite child?
I can't stand any of them if I'm being direct now, it's, it becomes a almost a religious debate at some point. Mm-hmm. Where did Falco DB come from? What is the, what is the origin story of it? Because frankly, I, one day someone decided to sit down, I'm gonna write a graph database. Sounds like a supervi origin story more than anything else.
Roi: Well, that's, that's what happened 10 years ago. Uh, with me. I was, um, I took a course, uh, at the university that had dealt with graph, and I just fell in love with this idea of graphs. Um, and, uh, I thought that back then I thought that it would be interesting to extend Redis capability with, uh, a graph data type.
Back then Redis just came out with its ability to extend, uh, the database with modules, read this modules, and I thought it would be a nice idea to have a graph data type and some graph capabilities within reds. So, um, I worked on that project for a while. I think it was about, uh, six months. And then I met with the, the Redis folks and I, you know, showed them what I've been up to and they said, oh, that's really interesting.
You should come and join Redis. Um, so I did, and within Redis I've built Redis graph. So we turned this six month. Uh, worth of work at home into an actual product. Um, I've done that at Redis for about six to seven years, building and developing Redis graph, um, which eventually Redis decided to abandon or, you know, shut down the project.
And, uh, myself and two other colleagues of mine thought that it would be a shame to see this project. Go down the drain. And so we decided to spin out of Redis and turn Redis graph into what now is known as Fal Cord db. So we've basically just continue on from where we've left off at Redis. Um, and we've been doing that for over two years now.
So around 10 years in total. I'm involved in building and, you know. Getting a graph database out there, which is competitive. Um, so yeah, that's, that's the background story behind File Core.
Corey: This episode is sponsored by my own company, duck Bill. Having trouble with your AWS bill, perhaps it's time to renegotiate a contract with them.
Maybe you're just wondering how to predict what's going on in the wide world of AWS. Well, that's where Duck Bill comes to help. Remember, you can't duck the duck bill. Bill, which I am reliably
Roi: informed by my business partner is absolutely not our motto. To learn more, visit bill hq com.
Corey: How do you find that it has been to run effectively?
What is a. I, I, I have to be careful using terms like open source, people get salty about this, but you are source available. Uh, do you find that it is tricky to run a viable business where there's also the story of, or you can just use the code and all the stuff that we build for free and make available to everyone?
I, I, I think I understand that it's somewhat of a leading question and a naive one, but I am curious to get your take on it.
Roi: Yeah, I mean, it's tricky. It's a question that pops up. Uh, from time to time, I think that the, the benefits of having your product as an open source are greater than having it as a closed source.
Um, what happens is that your adoption rate is much, is much greater when you have your product, um, available for free on the other, on the other end. Yes, it's a bit frustrating to see all of those people who are using the product and. Are not chipping, chipping in. Uh, but I mean, at the end of the day, for me, it's a, it's a huge, um, it's, it's just a pleasure to see, uh, the work that I've done being used all over the place.
And it, it comes as a surprise. You know, we, we are not aware of all of the use cases and all of the people who are using the product. And when somebody reaches out. Uh, and we, you know, have a conversation with him and you see the product being used for a variety of, uh, workloads and use cases. It, you know, you feel, you feel great about that.
In addition, the fact that it, it is source available, people can submit issues, people can have a conversation about it. Um, there is, there is benefit to it. So if you look at our Gita page, you'll see. Um, plenty of issues. Um, and I think it's, it's great to have GitHub issues because it shows that people are, are using the product and they're, and, and they care enough to go and, and open an issue.
Um, and so we, we learn from that. I mean, it's kind of like a free QA to the product we might be able to produce or to generate more revenue if we were closed source. But I think that the, the benefits of having something open and making some contribution to the open source community. Um, does pay off, uh, at the, at the long climb,
Corey: apparently.
Uh, back in 2024, you folks did a, uh, an announcement about rewriting Alcore DB and rust. Mm-hmm. Uh, that often. I, my snide comment has always been the primary IDE of a rust developer is PowerPoint because it's impossible to do anything in rust without doing a whole dog and pony show around it. Uh, has that been completed?
How'd it go?
Roi: No, it's still a walk in progress. Um, my other, uh, co-founder Avi, is in charge of doing the, the vast right at first. We've tried to do that in a gradual form, so we have this relatively large C code base. I'm a big. C fan. I, I am a, I wouldn't want to program in any other language, but C Oh,
Corey: that, that'll get you hate mail just for that statement alone.
Roi: Uh, maybe I, I mean, I'm 42 years old. Um, so maybe that's the, you know, the, the age.
Corey: Yeah, we are a gentleman of a certain age and yeah, at some point learning the latest new, trendy things, it just feels like it's more trouble than it's worth. If I'm being direct,
Roi: I, I just like the simplicity of the language.
I don't like, uh, the fancy interfaces and I don't like, you know, things being hidden from me. The type of programming that it is needed for, to develop a high performance curve database, you need to be aware or, and in control of. Practically anything that happens in your system and any language that hides stuff from you, uh, and the language that would not give you absolute control over the instructions and the memory layout, you would simply, you know, would not be able to fully utilize the hardware.
Just circling back to the Russ question, so we, we, the first, we try to do it gradually. Taking apart, uh, components that are ancy and reit them in and integrating them back, that didn't work too well for us. And so, uh, after a year of trying this out, we've decided that this approach would not work. And so we're gonna write everything in one go the entire thing from Sketch.
So that, that's gonna take a while in my mind. Um, they're, they're due, you know, they did make a good progress, uh, but it's still not there just yet. Um, I'm more focused on the C,
Corey: so Pirate's favorite language. Some people think it might be R, but the Pirate's first. Love is the C
Dad. Jokes do not get better from here. I store them in a database. There's a separate, there's a whole spiel we can go into and we'll avoid for brevity's sake. What I guess is the, the challenge I've always had, and I suspect I'm not alone in this, is I keep seeing graph databases and I see things that are interesting, but I, I'm missing a toy problem that feels like a good fit for it.
Um. Take a relational database and great, I'm going to go and build even something dumb like a to-do app, which is still overkill for some of that. Or I'm going to build something that will track books in a library, uh, with, and you get multi table stories with authors and books. And the rest I, what is, I guess, the toy problem, uh, minimum viable footprint that isn't insane for a graph database.
Roi: So I have, uh, maybe two examples. We've recently done a webinar about. Our UDF capabilities, user, user defined functions, uh, within the database. And, uh, the, um, project which showcased this was farm to table. So the idea was in this graph you have nodes, entities representing forms. Those are connected to delivery hubs.
Which might connect to other delivery hubs, but eventually they would reach a store like Trader Joe's. And basically what you want to do is to find a path that would get the produce fruits and vegetables and keep them as fresh as possible to the store.
Corey: So in other words, it's an implementation of the traveling salesman problem.
Roi: Yes, you can You, I mean, you can think about it that way. It's a path finding problem. Where you want to optimize, uh, some function in, in our case, it was the, the freshness of the food. Uh, but you can also look at it and say, okay, I want to, uh, find the path which has the minimum cost of transportation. So that's maybe one example where, you know, we got databases, uh, are, are a great fit.
Another one, which, you know, people. It can relate to is access management. So think about a big organization with lots of users and those users are, uh, grouped into groups and there might be a group hierarchy. And then there are resources such as servers and files and folders. And every time a user tried to access one of those resources, you need to make sure that he has the right axis.
And so this once again becomes a, a path finding problem. If you think of it, you need to see if there is a path. Connecting that user through a set of different groups to the end, uh, to the end resource. So we actually have a number of. Customers who are using Falco tb Exactly. For this,
Corey: my last question before we wind up calling this an episode is open source, source available, et cetera.
Great. Awesome. Your code is on GitHub and accepts contributions from the larger community. I have heard a lot of open source maintainers. Uh. I have some minor stuff up, but you know, we're talking to actual people who are serious about this stuff. Uh, they are inundated with a barrage of AI generated pull requests.
The quality of which is, uh, will be polite and say varies widely. What has your experience been with that
Roi: faculty? B is is not an easy product to contribute code to. So if we're getting some contributions, it's, it's very rare and we're very happy to receive them. That said, a few, a few years back before, uh, you know, all of those new AI tools, whenever a PR showed.
Uh, it was obvious that the, there was a person behind that PI who took the time and wrote the, the piece of code that he wanted,
Corey: right? Someone cared. Uh, my fir, one of my early exposures to the open source world in that sense was with SaltStack. Tom Hatch was a phenomenal founder of that project and company 'cause he would accept.
My shitty poll request, and then he would thank me for it and then immediately rewrite it so it was good, and then submit that as a second poll request within minutes, which does not scale for crap, but it was so welcoming and so. You belong here, that it really led to an amazing community for a while that doesn't scale.
And I'm not suggesting anyone should necessarily follow that pattern, but man, was I fortunate to encounter that,
Roi: that, I mean, that was a great gesture on his behalf. Um, I feel like, you know, if, if I am, if I think that PI is, uh, addresses a real issue and uh, there's a good justification to add it. It's, it's very likely that I would do some rewriting to it or ask the, the,
Corey: you can also, this was also a different era.
You can assume good faith. Back in 2012 when I was doing these things, now for all, you know, someone just threw something into a slop cannon and basically said, I need to have another one for my resume. Go, go submit a pr. And they don't, they don't know what the project is. They don't care about it. At least historically, it used to be people going through and fixing the comma.
Placement in your docks fine, whatever. Now it's a lot harder to tell.
Roi: We actually open, uh, a few. We have a number of issues that we are opening to get help from the public and we're willing to pay for those prs.
Corey: Oh, no, that, I'm sure this will not cause an in influx of AI generated prs. Oh no.
Roi: Yeah, that's exactly what is happening these days.
Uh, people try to know too. Address those PIs and collect, uh, that money by simply throwing an AI at it. And then we're, we're, you know, we're bombarded.
Corey: We've seen crap like this. Like I get at this on my security email inbox all the time for last week in AWS, which is again, a podcast and an email newsletter.
It is not a SaaS app or anything like it. And they're always finding the same things of you're not. Enforcing hard fail for SPF on your emails because if you do that, it will in fact cause some problems with email forwarding in some newsletter edge cases. So there you should fix that. Pay me please. Like, what the hell is this?
It's the lowest effort. It's the beg bounty. It's awful. Awful.
Roi: We're getting those as well. Um, I mean, at least twice a week. I'm getting an email of that sort. I don't know. It's a, it's a new era. I think
Corey: it is, and I would not wanna be starting my career in this era. I, I don't have a better path for this.
The, the roads you and I walked have long since closed. It's the world's a different place. I, I'm always scared to give Boomer tear advice of, well, back in my day, just you print out your resume, a nice paper, and you walk into the office and you demand to speak to the owner and you have a firm handshake and hit the bricks.
You'll have a job by sundown. Yeah, sure. That'll work. Now they'll call the police.
Roi: I see people, colleagues of mine or you know, family who. Who are working, uh, in the tech industry and the picture that they paint is, is, is pretty awful. I mean, from my perspective, people who, you know, call themselves poels, are not, are not typing anything in the keyboard except for handing, handing their, uh, work over to an AI and then just ing stuff in without even looking at it.
And then you ask them, you know, okay, how does it work? Or maybe you can walk me through this. And the answer is, I have no idea. AI generated it. And so I think, I think that's a very dangerous route to take.
Corey: I mean, there is the counterpoint too. I look at this thing like, how does this work? I don't know. I wrote it six months ago like that.
That was always my answer too. It's like, honestly, I don't know what the hell me of six months ago was doing, but he was terrible.
Roi: I can, I can relate to that as well. But
Corey: how many times in your career have you been like, what idiot wrote this? And you fire up, get blame, and it turns out it was you. So you quietly fix it, don't say a word, and then just go ahead and patch it.
Yeah. Yeah.
Roi: It's fun to look back and see, you know, how you as an individual. Developed over, over the years, especially if you are involved with certain
Corey: values of fun. Yes.
Roi: Uh, I mean, if you are involved in the project for, uh, for a few years, then hopefully you, you do get to evolve and it's nice, you know, to have this last retrospect and see.
How, how was the code that you, you have written five years ago and, and where you're at right now? Hopefully, hopefully you have improved, but, but, but these days, you know, people who are, uh, using ai, uh, to the point where they, they don't give it, they don't, don't even get the chance to practice their craft.
Um, yeah, I think that's problematic. People are saying it is, you know. Um, in, in my area, people are saying that new developers, juniors are very, are having a really hard time, um, getting work. And so I, I, I wonder, uh, where, where would we find the, the seniors, the 15 years ahead of us, the, the seniors from, where are they gonna come from?
Corey: That's the thing that I've been pointing out to people. When I first found that AI could write some code and showed it to some friends, their responses, well, this is great to replace junior engineers, but it won't replace senior engineers up. Where, where do you think senior engineers come from, buddy? Uh, they don't spread early form from the forehead of some God somewhere.
Roi: Exactly. And, and maybe some would argue that in the, you know, in the near future, seniors can also be. Replaced. I, I don't know. I think that at the moment LLMs are having difficulty to work with large code bases. Uh, I do see them as a great utility to start out something new. Whenever there's a clean slate and you ask it, okay, bill for me from scratch something, it might, you know, work well, it might work well for applications that are not.
At the system level, um, maybe fronted front end type of work, maybe some backend type of work, but to build, I dunno, 20,000 line worth of, uh. Some high performance, high quality, uh, application database.
Corey: Yeah. My version of UX is around ergonomics of command line tools. I am not a front end person. This, this has been an unlock for a lot of different use cases there, and it's powerful, but I'm also not sitting here thinking I can build a reasonable front end for anything of scale.
The counterpoint is, I think that's a, that's a dangerous point. Like, well, that's not gonna scale at in any meaningful way. It's a back of house application for one email newsletter to get from one API to another. Maybe it doesn't have to scale. Maybe in the event that there's an outage in something, we can send the newsletter a half hour later.
Maybe. It's not a concern. It's, it's fit the problem for business case, because by the time you go from concept that you're puttering around with one evening on your laptop to a hyperscale service, you're gonna have rewritten that thing a dozen times over already. Anyway,
Roi: I, I agree.
Corey: Like my favorite part, especially a startup founder myself, is every time you hire someone, they're better at the thing that you're hiring 'em for than you are.
So it's a constant state of being humbled by these things and watching people in the interview trying to put a diplomatic corporate spin on what the hell is wrong with you? Why would you do it this way? Which, well, it got us this far to hire you, so please come help fix it. Uh, if, if people wanna learn more about Falco DV and graph databases at large, where's the best place for them to go?
Roi: Well, they can check out our website, uh, they can check out our documentation. Uh, I dunno if, uh, we're gonna, uh, include the links to those or Well, we
Corey: absolutely can put those in the show notes for you. It'll be fine.
Roi: Then our documentation, our website and our disco channel. This is where. Uh, you can reach out and, uh, learn about, uh, our product or our service and on graph, uh, generally.
And if you are, you know, interested in the actual source code and see seeing what I'm working on, then you can check out our GitHub, which is Falco db at falco db or slash falco db.
Corey: All of that will wind up in the show notes. Roi, thank you for taking the time to speak with me. I appreciate it. Thank you,
Roi: Colby.
It was fun.
Corey: Likewise, Roi Lipman, CTO, and co-founder of Falco db. I'm Cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast. Please leave a five star review on your podcast platform of choice. Whereas if you didn't enjoy this podcast, please leave a five star review on your podcast platform of choice, along with an angry, confused comment that makes it sound like you're a zookeeper.
Understanding why giraffes need their own database.