ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Product Release

Python joins JavaScript and Groovy as a first-class scripting language

The SQL console and script runner now accept Python: lang=python routes to the GraalPy engine, the console adds Python detection, and a shared polyglot module bridges JavaScript to both Python and Groovy.

Python becomes a first-class option in the console and the server-side script runner, alongside JavaScript on GraalVM and the recently added Groovy engine. A console request marked lang=python now dispatches to the GraalPy runner instead of falling through to raw SQL execution.

Python in the console

  • Explicit and detected. The console language dropdown adds a Python option, and auto-detection recognises Python signals — a shebang, def, print(), elif, from ... import — while excluding a bare import to avoid clashing with JavaScript.
  • Typed dispatch. A Python request is wrapped as a typed script block so the parser routes it to the existing GraalPy engine, while JavaScript keeps the default engine and tag.

Cross-language bridge

  • A dedicated polyglot module. The polyglot helper, previously a JavaScript-only utility, moves into its own module now that it bridges JavaScript to both Python and Groovy, and is reachable as Ax.polyglot.
  • Groovy over JSR-223. A callGroovy bridge reaches Groovy through the JSR-223 engine rather than the GraalVM polyglot API, which cannot resolve Groovy as a guest language, while sharing the host engine's live runtime.

JavaScript remains the default; Python and Groovy are opt-in, and all three share the same runtime library and permission model.

See the feature →

← All posts