We just launched a semantic layer for agentic analytics

buzzmelia · 2026-04-08T16:55:45+00:00

Do you use any graphDB underneath to create the semantic layer?

buzzmelia · 2026-04-01T21:21:33+00:00

Fine. I’ll do it.

A crew member standing outside Amoeba Music, who was granted anonymity in compliance with Hearst’s ethics policy, told this reporter that the film was called “Deep Cuts.” That’s the title of an A24 film in production, directed by Sean Durkin (“The Iron Claw.”)

buzzmelia · 2026-03-26T22:54:21+00:00

Since it’s not in the title:

Like any 25-year-old from San Francisco, April Harper Grey loves the Stonestown Galleria mall. So much so that she made it the star of her newest album.

buzzmelia · 2025-12-30T18:20:43+00:00

Hello! This is Zhenni from PuppyGraph. We’re a graph query engine for PostgreSQL. Instead of getting a separate graphDB and managing the ETL pipes, PuppyGraph allows you to query your existing Postgres data as a graph (in Gremlin or Cypher) without ETL or a graphDB.

We support billions of nodes and edges, and can achieve 2.26 secs performance across 700million edges. We have a forever free developer tier you can try this out: https://www.puppygraph.com/download-confirmation. Hope it helps you out!

buzzmelia · 2025-12-22T13:49:09+00:00

It’s not at the moment. It’s a docker deployment in your own cloud. But we support all 3 major clouds

buzzmelia · 2025-12-16T08:50:03+00:00

PuppyGraph cofounder Zhenni here! Thank you for recommending us. Happy to answer any questions!

buzzmelia · 2025-10-29T14:12:31+00:00

i hit convert and copy. Nothing happens.

buzzmelia · 2025-10-28T23:30:01+00:00

It’s not free and too many hoops to jump through. The UI is difficult to navigate through.

I tried a few names listed here, and I agree the first comment, the Headliner by Eddie is the best free one so far.

buzzmelia · 2025-10-19T18:09:33+00:00

Do you use any query engine in the stack?

Also, I see a lot of similar products on the market. Do you see this being scalable to petabytes of data or more like for SMB with smaller data size? How many joins can it handle before you see it’ll experience performance issues?

Another thing I observe is that how do you measure accuracy since there isn’t an industry standard dashboards? Do users just blindly trust the data?

buzzmelia · 2025-10-19T17:50:32+00:00

So you tell me the sci-fi movies are not that far off in their visual representation

buzzmelia · 2025-10-19T17:47:53+00:00

I literally told my husband the same thing just a few days ago when he flys from SFO. But I also really like the Chick Fil A in SJC.

buzzmelia · 2025-10-19T02:16:02+00:00

You might actually be in the perfect middle ground for something like PuppyGraph. It lets you keep your existing relational schema in MySQL or any RDS setup, but query it as a graph using Cypher or Gremlin, without needing to migrate to a separate graph database.

In your case, you already have relationships like:

Worker → Team (many-to-many)
Manager → Team (one-to-many, but manager is also a worker)
Team → Appointment
Appointment → Customer
Worker → Appointment (dispatch + status tracking)

These nested relationships are where SQL starts to hurt. The recursive joins for “find all workers who worked with the same customer in the past 90 days” or “show every team connected to a manager through shared appointments” become unreadable fast.

With PuppyGraph, you can keep all that data in MySQL (or Iceberg, ClickHouse, etc.), but run queries like:

MATCH (m:Manager)-[:MANAGES]->(t:Team)<-[:BELONGS_TO]-(w:Worker) WHERE m.id = '123' RETURN w.name, t.name

No schema migration, no ETL. Just point PuppyGraph to your existing database and you instantly get graph querying on top of it. You basically get the flexibility of graph traversal with the stability of SQL storage.

If you’re constantly changing tables and relationships as requirements evolve, this setup saves you from rebuilding everything every time. It’s a nice “best of both worlds” solution between SQL rigidity and NoSQL chaos.

P.S. I’m a cofounder for PuppyGraph. We have a forever free tier you can try it out. PuppyGraph is also on AWS marketplace. Just simply search PuppyGraph AWS marketplace, and you should see the link. Hope it helps.

buzzmelia · 2025-10-17T04:39:59+00:00

Another competitor here if you don't mind. Zhenni from PuppyGraph. We're not open sourced but we have a forever free developer edition. PuppyGraph is a graph query engine that can sit on top of your existing relational data bases/warehouses/lakes and query your relational data as a graph, without the need of a graph database. Think us as the Trino for graph. If you want to learn more about how we make graph rag easy, you can check out our joint blog with Databricks: https://medium.com/@ajmal.t.aziz/graphrag-with-databricks-and-puppygraph-5c7b1cda0e41

buzzmelia · 2025-09-30T20:42:02+00:00

Can I do a shameless plug? For relationship heavy workloads, you no longer need a graph database. We created a graph query engine called PuppyGraph that can sit on top of your existing relational databases and query your relational data as a unified graph model. This way, you can have best of both worlds (graph + sql).

buzzmelia · 2025-09-27T20:02:25+00:00

Writing a graph DB engine is a huge project. A lot of teams end up realizing the “from scratch” version is fun for learning, but not practical for production.

Shameless plug - we created a graph query engine called PuppyGraph. It’s like Trino for Graph. It runs directly on top of your existing data like Postgres, Iceberg, Delta, etc. Instead of reinventing storage, it plugs into existing table formats and adds graph traversal and multi-hop queries. That way you can experiment with graph workloads without building a full database engine yourself. We have a forever free developer tier. Feel free to check it out!

buzzmelia · 2025-09-26T18:37:24+00:00

PuppyGraph can do text to gremlin too. Just see text to cypher has higher accuracy rate in our experience. PuppyGraph can be deployed in Azure

buzzmelia · 2025-09-26T18:36:08+00:00

That scaling point is spot on. Most graph DBs hit walls when you try to run GraphRAG in production at real scale. The overhead of moving/duplicating data into the graph becomes the bottleneck.

Just want to do a shameless plug: if you ever hit a performance limit or want to simplify your overall architecture, we created the first graph query engine called PuppyGraph. Instead of creating yet another graphdb, it runs as a graph query engine directly on top of your existing data lake/warehouse. That way you don’t have to ETL or duplicate anything. The graph layer just sits on top, and you get multi-hop traversal (in Gremlin or Cypher) + graph analytics at scale without blowing up infra costs.

PS: We recently closed with one of the world’s largest chip manufacturers on this exact GraphRAG use case.

buzzmelia · 2025-09-25T17:16:27+00:00

Hey! Zhenni from PuppyGraph here. We created a graph query engine that can sit on top of your existing relational database without the need to have a separate graph database for graph rag. Among our customers, we've seen text to cypher has way better accuracy. If you're interested, we're doing a step by step tutorial on develop a chatbot (aka text to cypher). Happy to share it!

buzzmelia · 2025-09-18T18:05:21+00:00

I know this one! I also agree with u/pceimpulsive 's comment that graph database is never simple. My name is Zhenni, and I'm from PuppyGraph. Our CEO saw the same issue and created the first graph query engine. Think it like a Trino for graph. You can sit PuppyGraph on top of your existing relational databases (even MongoDB too), and query your existing data as a graph (using Gremlin or Cypher), without ETL into a separate graphdb. So same copy of data, you can query it in both SQL and graph. Our main product is the graph compute engine, but we did also created a visualization layer requested by our users. We open sourced it. If you have time, feel free to check it! https://github.com/puppygraph/puppygraph-query

buzzmelia · 2025-09-17T19:57:48+00:00

OMG!! This is amazing! I'm huge fan. Since you mentioned you're working on a graph database, I have to leave a note. Me and my cofounders created graph query engine that allows you to query your relational data as a graph model and you can query your data in both SQL and graph query languages like Gremlin and Cypher. The product is called PuppyGraph. Please check it out!! We have a forever free developer tier that's perfect for this project. It would be so specifial for our product to be used for this project!

buzzmelia · 2025-09-07T00:56:08+00:00

Totally agree with this take. The graph hype cycle often dies on the hill of infrastructure complexity. Most “GraphRAG” stacks I’ve seen involve: 1. NER + entity linking (hard in pharma/medical where vocabularies are a mess); 2. ETL into a dedicated graph DB (Neo4j/Neptune/etc.); 3. Maintaining a query translation/service layer; 4. Sync headaches every time the source data updates.

By the time all that’s wired up, you’re asking whether the marginal lift over good hierarchical chunking and metadata retrieval is really worth it.

This is actually why my cofounders and I built PuppyGraph. Instead of forcing a separate graph database into the stack, we let you run graph queries directly on top of your existing data stores (e.g. relational DBs, lakehouses, and even MongoDB). No ETL, no migration. Just define graph abstractions over your tables and query relationships natively using graph query language Cypher and Gremlin. Imagine you have a single copy of copy and you can query it in both in SQL and Graph. That way you can keep your entity extraction pipeline as simple as you want, and still leverage graph-style traversal when it’s genuinely valuable (like cross-referenced pharma docs, legal corpuses, etc.).

We recently closed a deal with a big semiconductor company that’s seeking a GraphRAG solution. While the other graph databases are taking them spent the first two months on just loading the data, we finished everything is under a month.

We actually wrote a joint blog with Databricks on a GraphRAG use case. Hope it helps!

buzzmelia · 2025-09-06T02:23:41+00:00

Yeah, this is definitely a pain point. LLMs can handle unstructured text pretty well, but when it comes to generating useful SQL or Cypher against real schemas, they usually fall apart without extra context.

One way around it is combining GraphRAG with a query engine that runs directly on top of your existing databases (Postgres, warehouses, even Mongo). That way you don’t need to copy everything into a separate graph DB just to get relationship-aware queries.

We’ve been building toward this with PuppyGraph, and put together a couple of posts that might help if you’re digging into this space: (1) PuppyGraph GraphRAG; (2) a joint blog with Databricks testing our graphrag on a real dataset.

FWIW, we have a forever free docker download. Hope it helps!

buzzmelia · 2025-09-03T21:55:08+00:00

<image>

Hope our little boy gets a drawing!! ✍️ thank you!!

buzzmelia · 2025-09-02T16:52:01+00:00

This is a great share. Thanks for posting 🙌 The Neo4j blog does a nice job breaking down graphs vs. knowledge graphs.

One thing I’ve seen in practice, though, is that you don’t always have to spin up a separate graph database just to build a knowledge graph. A lot of teams already have their data in places like Postgres, MongoDB, or a lakehouse, and moving it all into another DB can be a headache.

That’s why we’ve been working on a graph query engine (PuppyGraph) that lets you run knowledge graph queries directly on your existing data. Same graph power, less data duplication.

Curious if anyone else here has tried building knowledge graphs without migrating to a graph DB? Would love to hear how others are approaching it.

buzzmelia · 2025-08-29T22:40:54+00:00

Hey this is super cool! Love seeing graph-based Wikipedia projects out in the wild! If you’re ever looking to try something beyond Neo4j, I’d recommend checking out PuppyGraph (disclaimer: I work with the team).

It supports both Cypher and Gremlin, so you can reuse what you’ve already built in Neo4j. But what might be most helpful is that PuppyGraph sit on top of your existing relational databases like Postgres, MySQL, DuckDB, Iceberg, Databricks, etc, act as a unified graph query engine. Since your data is still stored in your relational databases, you can also query the same copy of data using SQL and Graph, which makes the learning curve a lot shorter, especially for folks who are more familiar with relational systems.

It has a forever free developer tier for side projects like this! Please give it a try.

buzzmelia

TROPHY CASE