Relate – the agent-native graph database(relatedb.ai)
18 pointsby jonbaer5 hours ago3 comments
  • threecheese3 hours ago
    The codebase ADRs are very interesting; you can view the process of building the database, in the order in which it happened.

    Looks like they took many design decisions from neo4j, and started (-ish) with an ontology that describes the graph's design itself (rather than describing _a_ graph).

    You also get to see some technical decisions, like WAL etc. Very SDDish.

    • johnymontana3 hours ago
      There's even a cookbook example using the relate ADRs to analyze the codebase decisions using relate itself: https://relatedb.ai/cookbook/codebase-context-graph/

      Like a context graph for your codebase. Code analysis for agents is one use case I think makes a lot of sense for relate.

      • tamimioan hour ago
        Ok, so right now I have my ADRs as part of my blueprint, and of course each also links to other related adr. How’s this any different than just keeping them in markdown files?! Just the graph?
        • johnymontanaan hour ago
          Markdown stays the source for the ADRs so the graph is more like a derived index built from the markdown sources, rather than a replacement. The graph gives you (and your coding agent) the ability to ask questions about the relationships between decisions, which you can do with markdown only by reading them all.

          Markdown makes it easy to find things like "what does this ADR link to?" The graph allows for questions like "what links to this one, what replaced it, did whatever replaced it get replaced too, and which modules depend on code governed by a decision that's been superseded?"

          • tamimio39 minutes ago
            > what links to this one, what replaced it, did whatever replaced it get replaced too, and which modules depend on code governed by a decision that's been superseded?

            Very interesting, as right now I have some sort of a header for each adr with some details including what supersedes it, but also status if approved/proposed, amendments, owner, blueprint version, and other details to track them. Will try it and see how it goes in my ~300 adrs. Is it adr only or does track other parts of the blueprint? Like specs, architecture, etc.?

  • mring336214 hours ago
    From the Neo4J people!
  • tekacs3 hours ago
    In the example:

      > What do you remember from our last session? 
  > ... 
  > WHERE e.session = 'last'
  >
    Not that you couldn't model it this way, but not exactly filling me with confidence that this has been looked at closely.
    • johnymontana3 hours ago
      something like this perhaps to find the latest event:

          WHERE NOT EXISTS ((e)-[:NEXT]->(:Event))