Remote development support

Hi mbund, let me go through your points one by one.

1) Where can I find more documentation and examples about how to use it?

High-level overview of what “Jupyter notebooks in remote development” actually includes: https://www.jetbrains.com/pycharm/whatsnew/2025-3

Remote Development documentation - how to connect via SSH, JetBrains Gateway, containers, etc.: https://www.jetbrains.com/help/pycharm/remote-development-overview.html

General Jupyter notebook documentation, all of which also applies to remote projects:

https://www.jetbrains.com/help/pycharm/jupyter-notebook-support.html

https://www.jetbrains.com/help/pycharm/configuring-jupyter-notebook.html

https://www.jetbrains.com/help/pycharm/running-jupyter-notebook-cells.html

A more tutorial-style blog post: https://blog.jetbrains.com/pycharm/2024/09/how-to-use-jupyter-notebooks-in-pycharm

2) Does this mean that I can now run individual cells on a remote machine? Can I change the interpreter for different cells?

Yes, you can run individual notebook cells on the remote machine when using Remote Development.

No, you cannot assign different interpreters/kernels per cell - Jupyter itself doesn’t support that model.

Each notebook is attached to a single Jupyter kernel (which corresponds to one remote Python environment). You can switch the kernel for a notebook via the kernel selector in the notebook toolbar. If you need mixed languages or tools within one notebook, you can still use Jupyter magics like %%bash, %%sql, etc., or split the logic across multiple notebooks.

3) Is it possible to use this feature with Databricks clusters? Or do I still need the Databricks plugin?

Remote Jupyter support in 2025.3 is designed for general remote environments - SSH hosts, remote dev containers, WSL, and similar setups where PyCharm has full filesystem access and can manage Python interpreters.

This feature does not replace the Databricks plugin.

For working directly with Databricks clusters, submitting jobs, managing remote notebooks, and integrating with workspace workflows, the Databricks plugin is still the recommended option.

You can combine approaches (for example, remote-developing into a VM that uses Databricks Connect), but for direct interaction with Databricks runtimes the plugin remains the appropriate tool.