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.
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.
This episode is sponsored in part
by
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
not our slogan.
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?
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,
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?
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
or working at Facebook
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.
That is definition of how roads should work.
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.
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?
In the universe of.
People building applications with ai,
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.
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
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?
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.
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
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.
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.
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.
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
informed by my business partner is absolutely not our motto.
To learn more, visit bill hq com.
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.
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,
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?
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,
that, that'll get you hate mail just for that statement alone.
Uh, maybe I, I mean, I'm 42 years old.
Um, so maybe that's the, you know, the, the age.
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,
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,
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.
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.
So in other words, it's an implementation of the traveling salesman problem.
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,
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
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,
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,
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,
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.
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.
Oh, no, that, I'm sure this will not cause an in influx of AI generated prs.
Oh no.
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.
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.
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
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.
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.
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.
I can, I can relate to that as well.
But
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.
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
values of fun.
Yes.
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?
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.
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.
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,
I, I agree.
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?
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
absolutely can put those in the show notes for you.
It'll be fine.
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.
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,
Colby.
It was fun.
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.