Add new cell type for Cypher that mirrors what SQL cells can do

[johnstegeman]

Description

For people who work with property graph databases that support the Cypher query language, it would be nice to have a new type of cell to support working with those databases. Neo4j, for example, has a python driver as well as a python library for visualizing the graphs returned by such queries. The cell could have an option to return a dataframe or a widget for visualization.

Suggested solution

I have a working prototype of this capability devloped with the help of claude code.

Are you willing to submit a PR? (You must receive approval from the team before submitting a PR.)

• Yes

Alternatives

No response

Additional context

No response

[dmadisetti]

I'm not certain we want to open up multiple different cell types yet- something we'd definite need to discuss a bit more- seems like a large can of works.

Would it be possible to register a cypher driver and maybe we have the return type render as a graph?
I'm not suggesting a solution just trying to spark discussion ! What would a specific cell type get you that a sql cell doesn't already?

Moving over to a discussion for now

[johnstegeman]

first - it gets linting / syntax highlighting. Registering a driver is something that my prototype does.

[dmadisetti]

Using our code mirror packages or additional ones? I wonder if we could expose lint / syntax information on the driver wrapper

[johnstegeman]

https://github.com/johnstegeman/marimo/tree/cypher - have a look at the code

[johnstegeman]

@dmadisetti would one of these be a better approach:

• Change SQL cell to "Database" cell or something similar and offer pluggable language adapters
• Offer a "plugin" architecture to add new cell types

[johnstegeman]

@dmadisetti

https://github.com/johnstegeman/marimo/tree/cell-plugin - cell-plugin branch.
docs https://github.com/johnstegeman/marimo/blob/cell-plugin/docs/guides/integrating_with_marimo/plugins.md

Cypher cell + neo4j connection plugin https://github.com/johnstegeman/marimo-cypher

Test plugin that just reverses the text in a cell https://github.com/johnstegeman/marimo-reverse

[dmadisetti]

This is ambitious and very cool- but I don't think we can support a plugin ecosystem right now, I wish we had a chance for a bit more discussion

What does this provide over anywidgets?

[johnstegeman]

the use case i see isnt on the cell output side, but on the input side. Marimo as it exists today has SQL type cells that abstract away all of the python boilerplate code for running sql and let you just write sql. As someone who works with neo4j and cypher query language, I'm jealous of that - I'd like my notebooks with cypher queries to be just as clean as the ones with sql. The visualization output I'm using in this poc actually spits out an anywidget provided by neo4j in their visualization library.

Happy to discuss further... does what I wrote enable something that can't be done today - no. I can and have written some helper functions that abstract away some of the boilerplate, but I'm still writing python code with queries in strings with that approach. Having a cell type that mirrors what you have already done with sql lets me have that same sql-like experience with a different query language - letting me and the people i am demonstrating to focus on the query and not have to think about the python boilerplate needed.

[johnstegeman]

the change to core marimo is ~300 loc, so not too invasive. Really simplifies the notebook when running Cypher code. Supporting as a third-party plugin makes it easy for database providers to offer a simpler UI experience for their database - especially when the database supports a query language other than SQL. The plugin code itself is fairly straightforward as well.

If a new cell type isn't a direction you want to go in (I get why you might not want to), and 3p plugins are also a non-starter, how can third parties offer this kind of capability other than through a fork (which I am averse to)? Happy to discuss more

[akshayka]

@johnstegeman, I truly appreciate the enthusiasm. Unfortunately lines of code are not proportional to maintenance; changes to open-source as I'm sure you know cannot be walked back, so any public API change needs to be scrutinized very heavily, as it adds not only unending maintenance but also a contract between us and our users that we can never change. We're just not at a place where we can do that for cell types.

Have you seen @koaning's anywidget for Neo4j? If not I'm sure he'll be happy to share. It's really cool, and if I understand provides similar functionality even if not full parity.

[johnstegeman]

thanks @akshayka - I have seen the widget. We've discussed it on discord as well. I get the concerns about new cell types or plugins. For now. I'm going to fall back to what I was doing (some small helper functions), which will hide some of the boilerplate needed.

[nojaf]

Hi there, we're interested in a custom input cell type. We use a custom DSL to query internal systems, so having support for that on the input side would be really helpful.

[nojaf]

What about an alternative that handles Cypher and every other niche DSL without marimo having to maintain any of them?

The Cypher request makes sense, but if we add it we're also saying yes to every other graph DB query language, every internal company DSL, every domain-specific syntax someone wants first-class editing for. That's a lot of adapters to carry and most of them won't be relevant to most users.

What if we made cell languages pluggable instead? A package like marimo-our-company-dsl could ship its own editor without touching marimo core at all.

How it would work

A package registers a language at runtime:

# somewhere in marimo_our_company_dsl/__init__.py
mo.register_language(
    name="our-company-dsl",
    wrapper="mo.our_company_dsl",                                        # how the cell is stored on disk
    js_module="/@file/marimo_our_company_dsl/our-company-dsl-editor.js", # bundled web component
    element_name="our-company-dsl-editor",                               # the custom element tag
)

The js_module is a web component the package ships. It owns everything inside: syntax highlighting, autocomplete, schema introspection, whatever makes sense for the language. Marimo just needs a thin contract:

• Marimo passes the raw DSL string as a code attribute (wrapper already stripped)
• The component fires CustomEvent("code-change", { detail: { value: "..." } }) on edits
• Marimo wraps/unwraps to Python on disk, same as it does for SQL today

On disk the cell still looks like plain Python: mo.our_company_dsl("""QUERY goes here"""). No new file format, no new serialization, and notebooks stay portable even without the package installed (cells just fall back to Python mode).

What marimo actually needs to change

The infrastructure is mostly already there. Anywidget does exactly this for output widgets, so we'd be reusing the same /@file/ virtual filesystem and dynamic import() mechanism, just pointed at the cell input instead.

Python: a small language registry + register_language() API, exposed to the frontend on session init.

Frontend: one new branch in cell-editor.tsx. If the cell's language has a registered custom element, load the module and mount it instead of CodeMirror:

const customLang = languageRegistry.get(language);
if (customLang) {
  await import(/* @vite-ignore */ customLang.jsModule);
  const el = document.createElement(customLang.elementName);
  el.setAttribute("code", dslCode);
  el.addEventListener("code-change", (e) => updateCellCode(e.detail.value));
  containerRef.current.append(el);
} else {
  // existing CodeMirror path, unchanged
}

Plus wiring registered languages into the language toggle UI dynamically. That's genuinely most of it. I'd estimate about a week of work total, and the anywidget precedent makes the dynamic loading part pretty low risk.

The upside for the Cypher case

The original request mentioned a working prototype. With this approach that prototype could ship as marimo-neo4j on PyPI today, with a proper Cypher editor, graph visualization in the output, all of it. Marimo core stays lean.

Things worth discussing

• Security is the same trust model as anywidget: JS from packages you explicitly installed. The isTrustedVirtualFileUrl check should cover it.
• Fallback when the package isn't installed: the cell should fall back to Python mode with the raw wrapper intact.
• Discovery: a marimo.language_adapters Python entry point group would let packages register without an explicit import.
• Built-ins vs. plugins: SQL and markdown stay built-in since they're core marimo features. The plugin path is for everything else.

Does this feel like the right direction or is there a reason to keep adapters in-tree?