Speaker 1: I want you to imagine a scenario for a second, like, really,
Speaker 1: picture it. Think about the most valuable piece of information
Speaker 1: in the world.
Speaker 2: Oh man, okay, I'm guessing people are picturing like a
Speaker 2: secret chemical formula or something.
Speaker 1: Right exactly, or you know, a hit or bank account number,
Speaker 1: or maybe a classified document. We always picture a specific
Speaker 1: isolated data.
Speaker 2: Point, yeah, a single thing in a volt exactly.
Speaker 1: But what if? What if the most valuable piece of
Speaker 1: information in the world isn't a single data point at all.
Speaker 1: What if the real value, the thing that actually drives
Speaker 1: the modern economy is the invisible lines connecting all of
Speaker 1: those isolated data points together.
Speaker 2: Which is wild to think about because it completely flips
Speaker 2: how we architect our digital systems. I mean, we are
Speaker 2: so conditioned by decades of computing to just, you know,
Speaker 2: focus on the individual pieces of the puzzle, the rose
Speaker 2: in a spreadsheet, yes, exactly, the rose, the documents in
Speaker 2: a folder, and we just completely ignore the architecture of
Speaker 2: how they all actually fit together.
Speaker 1: And that shift in perspective is exactly what we are
Speaker 1: exploring today. Welcome to this deep dive. Our mission today
Speaker 1: is to explore a fascinating stack of excerpts from the
Speaker 1: book Graph Databases, second Edition.
Speaker 2: It's a great rate, honestly, really is.
Speaker 1: We're going to look at how the tech giants of
Speaker 1: the world actually model reality, why the traditional databases you
Speaker 1: probably rely on every day are quietly failing under the
Speaker 1: weight of modern connections, and how a three hundred year
Speaker 1: old mathematical theory is secretly the engine running today's digital landscape.
Speaker 2: It's a lot of ground to cover, but it's so
Speaker 2: important it is.
Speaker 1: Okay, let's unpack this. Yeah, where do we even begin
Speaker 1: with mapping data like this?
Speaker 2: Well, to really understand what a graph database is, and
Speaker 2: you know why it was even necessary to invent one,
Speaker 2: we kind of have to go back to nineteen ninety nine. Well,
Speaker 2: the dot com boom exactly. We have to look at
Speaker 2: the sheer desperation that led to its creation.
Speaker 1: Desperation is a pretty reliable motivator for engineering breakthroughs. Right,
Speaker 1: what was the wall they hit back in ninety nine?
Speaker 2: So picture a twenty person startup. Everyone is working these
Speaker 2: brutal like twenty three hour days. The founders of a
Speaker 2: company called neofor j were building an enterprise content management application.
Speaker 1: Okay, so managing lots of files and stuff right now.
Speaker 2: Storing the actual content like the documents and the images,
Speaker 2: that was fine, But their software was managing highly complex
Speaker 2: access permissions and hierarchies.
Speaker 1: Like who is allowed to see what file and who
Speaker 1: their boss is.
Speaker 2: That kind of thing exactly, and the engineering team was
Speaker 2: spending more than half their time just fighting their relational database.
Speaker 2: It just couldn't handle the connections between all those items.
Speaker 2: Storing the connected data was complex and queerying it to
Speaker 2: see who had access to what was tremendously slow.
Speaker 1: So the bottleneck wasn't the size of the files at all.
Speaker 1: It was the complexity of the permissions webbing them all
Speaker 1: together precisely.
Speaker 2: It was a complete nightmare. So out of pure frustration,
Speaker 2: they realized they needed a system that natively embraced Eiler's
Speaker 2: eighteenth century graph theory waits theory.
Speaker 1: Are you talking about the seven bridges of Koenigsberg. Yes,
Speaker 1: that's the one where he proved you couldn't cross every
Speaker 1: bridge in the city just once, and in doing so
Speaker 1: he realized that the actual islands didn't matter, only the
Speaker 1: bridges connecting them.
Speaker 2: That is the exact mathematical foundation. Yeah, Euler basically abstracted
Speaker 2: away the physical land masses and focused entirely on the
Speaker 2: links Wow and the neo forj founders, they wanted a
Speaker 2: database that did exactly that. And this is a great
Speaker 2: detail from their origin story. Actually, they literally altavistad around
Speaker 2: the web looking for it.
Speaker 1: Altivisdad. That is a perfect callback to the pre Google era,
Speaker 1: just searching for highly specific database architecture, right alongside people
Speaker 1: looking for pet food onlycos Yeah, exactly, I assume since
Speaker 1: it was nineteen ninety nine, altivis that didn't give them
Speaker 1: a magical solution.
Speaker 2: They found absolutely nothing zero, So they decided to just
Speaker 2: build one from scratch. They wanted to keep all the
Speaker 2: reliable features of an enterprise relational database, the transactions, recoverability,
Speaker 2: data integrity, but build bild a data model for the
Speaker 2: twenty first century, which makes sense right, So they built
Speaker 2: what is now known as the labeled property graph model.
Speaker 1: Let's break down the mechanics of that model, just so
Speaker 1: we have a clear picture if I am visualizing this
Speaker 1: in my head. What are the actual building blocks here?
Speaker 2: Okay? So it has four main characteristics. First, you have nodes.
Speaker 2: These represent the entities, so the users, the documents, the
Speaker 2: physical location.
Speaker 1: Okay, got it. Nodes are the entities right.
Speaker 2: Second you have relationships. These are the directed named arrows
Speaker 2: connecting those nodes.
Speaker 1: The bridge is essentially.
Speaker 2: Exactly the bridges. Third, you have properties. These are simply
Speaker 2: key value pair stored inside both the nodes and the relationships.
Speaker 1: Wait, stored in the relationships too, yes, both.
Speaker 2: We'll get to why that matters in a second. And finally,
Speaker 2: you have labels, which are tags like user or order
Speaker 2: that group specific nodes together so you can find them faster.
Speaker 1: Okay, I want to test my understanding here because on
Speaker 1: the surface that sounds I don't know, a bit like
Speaker 1: a fancy new cod to paint on something we already do.
Speaker 1: Hasse well if I am thinking about this like a
Speaker 1: sentence structure, the nodes are the nouns the people, places,
Speaker 1: or things, and the relationships are essentially the verbs that
Speaker 1: give the sentence action and meaning. But isn't that just
Speaker 1: a different way of describing a standard database joint.
Speaker 2: What's fascinating here is that in a graph database, those verbs,
Speaker 2: the relationships, they are first class citizens. They aren't an afterthought,
Speaker 2: meaning what exactly. In a traditional database, you construct the
Speaker 2: relationship at the exact moment you run the query Basically,
Speaker 2: by matching an ID in one table to an ID
Speaker 2: in another, you're building it on the fly, right. Okay,
Speaker 2: But in a graph, the relationship is physically stored on
Speaker 2: the disc as a distinct entity, and because of that,
Speaker 2: you can add properties directly to the relationship itself. Oh
Speaker 2: I see, Yeah, so you don't just know that Alice
Speaker 2: bought an item. The relationship itself holds the metadata like
Speaker 2: when she bought it, what the discount code was, the
Speaker 2: delivery method.
Speaker 1: So the connection holds just as much data as the
Speaker 1: entities it connects. That's crazy. Yeah, but if we are
Speaker 1: tracking every single interaction as a distinct, data rich verb,
Speaker 1: that architecture must be incredibly demand.
Speaker 2: It definitely changes how you manage resources.
Speaker 1: Yeah, how does this actually fit into a real world
Speaker 1: tech stack? I mean, are we talking about a system
Speaker 1: sitting directly behind the buy button on a website or
Speaker 1: is this something massive crunching analytics overnight.
Speaker 2: It actually splits into two distinct categories, and distinguishing between
Speaker 2: them is crucial. On one side, you have graph databases.
Speaker 2: These are your OLTP systems online transactional processing. They are
Speaker 2: designed for real time, highly available transactions accessed directly by your.
Speaker 1: Application, so they handle that split second moment when you
Speaker 1: click by yes exactly. And what about the analytics side.
Speaker 2: Those are graph compute engines. These are your OLAP systems
Speaker 2: online analytical processing. Think of tools like Google's pregl or cassivary.
Speaker 2: They are built for offline batch processing. They're designed to
Speaker 2: add or massive sweeping questions like scanning an entire social
Speaker 2: network to find the average number of friends of every
Speaker 2: single user globally.
Speaker 1: Oh wow, Okay, so the compute engine isn't running the
Speaker 1: data day application at all. It sounds like it needs
Speaker 1: to pull that data from somewhere else to do the
Speaker 1: heavy lifting it does.
Speaker 2: Typically, a compute engine pulls data from a system of record,
Speaker 2: which could be a traditional database or a graph database,
Speaker 2: using an ETL.
Speaker 1: Job extract transform loads exactly.
Speaker 2: It moves the data, over runs those massive global algorithms
Speaker 2: without slowing down the live website, and then returns the results.
Speaker 1: That make a lot of sense.
Speaker 2: But regardless of whether you are doing real time transactions
Speaker 2: or offline batch processing, the true power comes down to
Speaker 2: a structural concept called index free adjacency. This is the
Speaker 2: dividing line between native and non native graph processing.
Speaker 1: Let's unpack index free adjacency, because that sounds like heavy
Speaker 1: computer science jargon.
Speaker 2: It is a bit yeah if.
Speaker 1: I'm translating this is this basically the difference between having
Speaker 1: your best friend's phone number memorized in your head versus
Speaker 1: having to look their name up in a giant physical
Speaker 1: phone book every single time you want to call them.
Speaker 2: That analogy hits the underlying mechanism perfectly. In a non
Speaker 2: native system, the database might look like a graph on
Speaker 2: your screen, but underneath it is still consulting a massive
Speaker 2: index the phone book right, the phone book every time
Speaker 2: it needs to find a connected node. That look up
Speaker 2: takes processing time. But with native index free adjacency, the
Speaker 2: relationships are real physical memory pointers.
Speaker 1: So it just knows exactly where to go.
Speaker 2: Yes, the node for Alice literally contains the exact memory
Speaker 2: address for the node of her purchase. The database doesn't
Speaker 2: search for it, it just goes directly to it.
Speaker 1: That memory pointer concept is critical. But this brings up
Speaker 1: a massive pragmatic question. Companies already have massive clusters of
Speaker 1: relational databases like SQL or the new or Nosequel systems.
Speaker 1: They have spent millions engineering them. So if I am
Speaker 1: a CTO listening to this, So why can't I just use
Speaker 1: the systems I already have to map these relationships.
Speaker 2: Simply because relational databases, despite the name relational, are structurally
Speaker 2: terrible at handling rich relationships.
Speaker 1: Which is incredibly ironic, it really is.
Speaker 2: The relational model forces you into a rigid, tabular forms
Speaker 2: based structure. When your data is highly connected. You end
Speaker 2: up having to create massive join tables just to map
Speaker 2: which row in table A relates to which row and table.
Speaker 1: B right, and as the data set scales, those joins
Speaker 1: become a mathematical nightmare. You are essentially asking the database
Speaker 1: to compute the Cartesian product of two massive lists and
Speaker 1: filter out the matches.
Speaker 2: Yes, exactly.
Speaker 1: Plus if a user doesn't have a certain attribute, you
Speaker 1: end up with columns full of null values, taking up
Speaker 1: space and complicating the Coke exactly.
Speaker 2: The rise in connectedness translates directly into increased joins, and
Speaker 2: in SQL, joins exponentially destroyed performance.
Speaker 1: Okay, so SQL struggles, But the tech industry's answer to
Speaker 1: that over the last decade was no sequel. We move
Speaker 1: to aggregate stores, document stores, key value stores precisely to
Speaker 1: get away from rigid tables. Don't document stores solve this.
Speaker 2: They solve the schema rigidity, sure, but they are actually
Speaker 2: worse for connected data, really worse. Yeah.
Speaker 1: No.
Speaker 2: Single databases are brilliant at storing massive sets of disconnected documents,
Speaker 2: but the database itself is entirely blind to any connections
Speaker 2: between them. Ohis, to fake a relationship in no SQL,
Speaker 2: you have to embed foreign keys, literally typing the ID
Speaker 2: of document B inside document A. But the database doesn't
Speaker 2: know what that ID points to. It just sees a
Speaker 2: string of text.
Speaker 1: So it's basically dumb text.
Speaker 2: Right. Your application's code has to do the heavy lifting
Speaker 2: of pulling document A, reading the ID, and then asking
Speaker 2: the database for document.
Speaker 1: B, which introduces the performance killer you mentioned earlier. If
Speaker 1: I want to reverse lookups, say I am looking at
Speaker 1: a specific document for strawberry ice cream and I want
Speaker 1: to know every user who bought it, the document store
Speaker 1: has no better backward pointing links.
Speaker 2: None at all. In computer science terms, this is described
Speaker 2: using big O notation because there are no backward pointers.
Speaker 2: Finding who bought that ice cream requires an O of
Speaker 2: N operation.
Speaker 1: And the ND represents the number of items.
Speaker 2: Right, yeah, right. It means the database has to do
Speaker 2: a brute force scan of every single document in the
Speaker 2: entire system to see if it contains that ice cream's ID.
Speaker 1: That's agonizingly slow. Even some of the highly distributed stores
Speaker 1: that try to map relationships still struggle with this. Right,
Speaker 1: the sources mentioned systems like react which use one way links.
Speaker 2: Yeah, reac is a good example.
Speaker 1: But to query those links backward, they have to run
Speaker 1: latent map produce jobs. And a map produced job isn't
Speaker 1: a quick lookup. It's a heavy batch process that filters
Speaker 1: data across multiple servers, shuffles it, and aggregates it. You
Speaker 1: can't use a map reduced job to recommend a product
Speaker 1: while a customer is waiting on a checkout page.
Speaker 2: You absolutely cannot. The latency is just way too high.
Speaker 1: I think here's where it gets really interesting, because a
Speaker 1: clever engineer listening might just say, we'll find the database
Speaker 1: doesn't do it automatically. I will just build my own
Speaker 1: reverse indexes in the no SQL database.
Speaker 2: Oh, people try that all the time, right.
Speaker 1: They think, every time I write a purchase, I will
Speaker 1: manually add a backward link to the user. Does that
Speaker 1: solve it?
Speaker 2: This raises an important question about the true cost of
Speaker 2: distributed systems. Yes, you can denormalize your data and manually
Speaker 2: maintain backward links in your application code, but you trigger
Speaker 2: a synchronization.
Speaker 1: Nightmare because there's too many moving parts.
Speaker 2: Exactly, you immediately increase your right latency because every action
Speaker 2: now requires updating multiple separate documents simultaneously.
Speaker 1: And if the server blinks or crashes right between updating
Speaker 1: the ice Cream document and the user document, they are
Speaker 1: out of sync.
Speaker 2: And that creates what we call dangling references.
Speaker 1: Dangling references right.
Speaker 2: The user's document points to a purchase that the ice
Speaker 2: Cream document doesn't even acknowledge exists. Over time, those dangling
Speaker 2: references compound, harming data quality and forcing you to write
Speaker 2: even more code just to verify if the links are
Speaker 2: still valid before you use them.
Speaker 1: It sounds exhausting. So the theory is clear, SQL chokes
Speaker 1: on joins and no SQL pushes all the relational processing
Speaker 1: onto the application code, causing sync issues. But how does
Speaker 1: this actually play out when we put these databases head
Speaker 1: to head on a server.
Speaker 2: Well, the book neo Forge in Action details a brilliant
Speaker 2: experiment by authors Partner and vukotec Oh.
Speaker 1: I love this part.
Speaker 2: It's so revealing. Right, they set up a concrete head
Speaker 2: to head test between a highly tuned relational database and NEOFG.
Speaker 2: They modeled a standard social network one million people and
Speaker 2: gave each person approximately fifty.
Speaker 1: Friends, so one million nodes fifty million relationships. That is
Speaker 1: a very standard, realistic data set for a modern application.
Speaker 1: What was the actual test?
Speaker 2: They asked both databases to find friends of friends at
Speaker 2: increasing depths, basically expanding the network outward to see who
Speaker 2: knows whom?
Speaker 1: Okay, standard networking query, yeah.
Speaker 2: So at a depth of two just your immediate friends friends,
Speaker 2: Both systems performed perfectly. The relational database took point zero
Speaker 2: one six seconds and neofour j took point zero one seconds.
Speaker 2: To an end user, that difference is imperceptible.
Speaker 1: Okay, so tie game at the shallow end of the pool.
Speaker 2: But then they went to depth three friends of friends
Speaker 2: of friends, the relational database had to compute massive multi
Speaker 2: table joints. It took thirty seconds to run the.
Speaker 1: Query Wow, thirty seconds.
Speaker 2: Yeah, NEO four j using those native memory pointers took
Speaker 2: point one six to eight seconds.
Speaker 1: Thirty seconds versus a fraction of a second. If a
Speaker 1: web page takes thirty seconds to load a people you
Speaker 1: may know widget, the user has already refreshed the page
Speaker 1: or left the site entirely.
Speaker 2: Absolutely, and the math only gets more unforgiving from there.
Speaker 2: At depth four, the relational database took a staggering fifteen
Speaker 2: hundred and forty three seconds. Neofour j took one point
Speaker 2: three seconds.
Speaker 1: That is insane, and when.
Speaker 2: They pushed it to depth five, the relational database literally choked.
Speaker 2: It threw an error and couldn't even finish the query.
Speaker 2: Neofour j traversed the entire five deep network in about
Speaker 2: two seconds.
Speaker 1: We really need to pop on that number. Fifteen hundred
Speaker 1: and forty three seconds is over twenty five minutes. If
Speaker 1: you have to wait twenty five minutes for your architecture
Speaker 1: to realize that two people are loosely connected, your business
Speaker 1: operates in the past completely. If I'm running a modern business,
Speaker 1: the agility of one point three second query changes the
Speaker 1: fundamental nature of what I can offer the customer.
Speaker 2: It allows you to shift from historical analytics to real
Speaker 2: time recommendation engines. Let's map out a retail scenario.
Speaker 1: Okay, let's hear it.
Speaker 2: You have a user, Alice. She just puts strawberry ice
Speaker 2: cream in her cart because you have a graph database.
Speaker 2: You don't just see the ice cream. You instantly traverse
Speaker 2: the memory pointers to find every other user who bought
Speaker 2: that ice cream in the last month. Right then you
Speaker 2: traverse outward again to see what else they bought. The
Speaker 2: database detects a pattern. People who buy this ice cream
Speaker 2: frequently buy a specific brand of espressobeans, and crucially, they
Speaker 2: strongly dislike Brussels sprouts.
Speaker 1: And because that traversal took two seconds instead of twenty
Speaker 1: five minutes, you can cross reference those habits and recommend
Speaker 1: the Espresso means to Alice right there on the checkout page,
Speaker 1: before she even reaches for her credit card exactly.
Speaker 2: And it is not just shopping behavior either. We see
Speaker 2: this heavily utilized in geospatial data too. You can model
Speaker 2: physical locations as graphs using spatial indexing structures called R trees.
Speaker 1: Explain how R tree works in a graph context, just briefly.
Speaker 2: Sure, think of an R tree as a hierarchy of
Speaker 2: bounding boxes. You draw a massive virtual box around the UK.
Speaker 2: Inside that, a smaller box around London. Inside that, an
Speaker 2: even smaller box for the Battersea neighborhood, down to a
Speaker 2: specific postal code.
Speaker 1: Okay, Russian nesting dolls. Basically yep.
Speaker 2: Because a graph database natively understands hierarchies, it can traverse
Speaker 2: those bounding boxes instantly. If someone is standing in Battersea
Speaker 2: with their phone, you can do hyper targeted real time
Speaker 2: insights based on their exact coordinates. Or you can use
Speaker 2: those rapid traversals to detect fraudulent purchasing pattern right.
Speaker 1: Because fraud isn't usually an isolated event, it is a
Speaker 1: network of shared IP addresses. Stolen device is rapid transaction.
Speaker 2: Exactly.
Speaker 1: If you could traverse that network in milliseconds, you can
Speaker 1: decline the transaction before the bank even clears it. The
Speaker 1: power is just undeniable. But here is the final piece
Speaker 1: of the puzzle. I am struggling with what's up. If
Speaker 1: this architecture is so completely different from relational tables, how
Speaker 1: do we actually talk to it? I am obviously not
Speaker 1: writing a seql select statement to traverse a bounding box.
Speaker 1: Do I need a PhD in graph theory to query this?
Speaker 2: Not at all. There is an entire landscape of graph
Speaker 2: query languages out there. You have things like spark real,
Speaker 2: which is heavily used in academic data, and an imperative
Speaker 2: language called Gremlin, which gives you very low level control.
Speaker 2: But the absolute industry standard for property graphs is a
Speaker 2: language called Cipher. It is a declarative pattern matching language
Speaker 2: explicitly designed to be read by humans, not just engineers,
Speaker 2: but business stakeholders too.
Speaker 1: Wait, if it is not a massive block of SEQL
Speaker 1: joy in statements, what does the syntax actually look like?
Speaker 1: Am I writing something that looks like Python?
Speaker 2: No, you are essentially writing askart ass Yard.
Speaker 1: You're kidding.
Speaker 2: No, Really, think about how we solve problems in the
Speaker 2: real world. When developers and product managers sit in a meeting,
Speaker 2: they go to a whiteboard. They intuitively draw a circle
Speaker 2: for a user, a circle for an order, and they
Speaker 2: draw a hard line with an arrow connecting those.
Speaker 1: Sure we all do that.
Speaker 2: Cipher was built on the premise that you should be
Speaker 2: able to type those exact visual patterns directly into the database.
Speaker 1: So I am literally drawing arrows with dashes and greater
Speaker 1: than signs on my keyboard.
Speaker 2: You literally are in cipher. You put parentheses around a
Speaker 2: word to represent a circular node. You use a couple
Speaker 2: of dashes and a greater than sign to draw an arrow,
Speaker 2: and you put square brackets in the middle of the
Speaker 2: arrow to specify the relationship.
Speaker 1: That is amazing.
Speaker 2: You are literally telling the database engine search the data
Speaker 2: and return anything that looks like this picture.
Speaker 1: That is wild. It completely removes the semantic dissonance. I mean,
Speaker 1: in a traditional setup, you draw the elegant whiteboard diagram,
Speaker 1: and then the engineers have to go translate that beautiful
Speaker 1: concept into a brutal, abstracted series of database schemas and foreign.
Speaker 2: Keys exactly, and so much gets lost in translation.
Speaker 1: With cipher, the whiteboard drawing is the code.
Speaker 2: If we connect this to the bigger picture, that whiteboard
Speaker 2: friendliness is exactly what makes graph database is so highly agile.
Speaker 1: Ohso well.
Speaker 2: In traditional sequel you have to rigorously define your rigid
Speaker 2: tables up front, ironically, at the very beginning of a project,
Speaker 2: when you know the least about our data.
Speaker 1: Oh man, yeah, the worst time to make permanent decisions, right, And.
Speaker 2: If the business model changes a year later, migrating that
Speaker 2: rigid schema is a terrifying, error prone nightmare.
Speaker 1: Because a graph is essentially just a collection of connected dots,
Speaker 1: it is naturally additive.
Speaker 2: Exactly, if you launch a new product line, you just
Speaker 2: add new nodes, new labels, and new arrows. You don't
Speaker 2: have to rebuild the existing structure. The database evolves at
Speaker 2: the exact speed of the business's changing needs, rather than
Speaker 2: forcing the business to confor to rigid data tables.
Speaker 1: So what does this all mean? Let's bring this all
Speaker 1: together for you listening. We live in a world defined
Speaker 1: by its connectedness. Storing modern, highly interrelated data in isolated,
Speaker 1: disconnected tables or separate documents is just a massive missed opportunity.
Speaker 2: It really is holding businesses back.
Speaker 1: It forces your application codes to the heavy lifting of
Speaker 1: faking relationships, which destroys performance and creates synchronization errors. Graph
Speaker 1: databases solve this by treating the relationship as the most
Speaker 1: vital part.
Speaker 2: Of the data, first class citizens right.
Speaker 1: By using memory pointers to achieve index free adjacency. They
Speaker 1: allow you to query friends of friends of friends in milliseconds,
Speaker 1: completely bypassing the massive compute times that cripple traditional.
Speaker 2: Systems, and that speed and flexibility unlock capabilities we simply
Speaker 2: couldn't access before. In real time, it ships businesses from
Speaker 2: just looking at historical reports to actually predicting behavior in
Speaker 2: the moment, whether that is stopping fraud or providing highly
Speaker 2: nuanced product recommendations, which.
Speaker 1: Leads me with the final thought, I want you to
Speaker 1: moldup over. We've talked a lot about how graph databases
Speaker 1: map out these massive extended networks to predict what you
Speaker 1: will buy or who you might want to befriend. They
Speaker 1: act on patterns that might be five or six degrees
Speaker 1: separated from you, often predicting your behavior before you even
Speaker 1: realize what you want.
Speaker 2: Yeah, it's a little spooky, it is.
Speaker 1: It makes you wonder, as these systems get faster and
Speaker 1: more natively connected, how much of our daily behavior is
Speaker 1: truly independent free will, and how much is just a
Speaker 1: highly predictable path in a massive digital graph waiting to
Speaker 1: be traversed. Think about those invisible lines connecting the data points,
Speaker 1: because chances are you are standing on one of them
Speaker 1: right now. Thank you so much for joining us on
Speaker 1: this deep dive. We'll catch you an next TI