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 →
Engineering

Database connectivity, provisioned centrally and verified on load

Database drivers are now provisioned cluster-wide from the platform's central configuration store and verified by checksum before they load. The runtime no longer reaches the public Internet to fetch a driver, closing a supply-chain path on the boot line.

Every database an enterprise application talks to needs a driver, and where that driver comes from is a governance question, not a convenience. A driver pulled from the public Internet at runtime is an unverified binary on the boot path and a difference between one node and the next. This release moves driver provisioning onto the platform's own control plane: drivers are served from the central configuration store, verified before they load, and identical across the cluster.

The Internet leaves the boot path

  • Core engines travel with the platform. The drivers for the primary engines ship inside the platform itself and load without any network call, so a node brings up its database connectivity offline.
  • No runtime download. The runtime no longer falls back to fetching a driver from a public package repository; if a required driver is not provisioned, connection resolution fails fast rather than reaching outward.
  • Loaded in memory. A driver is loaded from verified bytes held in memory, with no intermediate write to local disk.

One governed source, consistent across the cluster

  • Served from the configuration store. Additional engine drivers are held in the platform's central configuration store and delivered to every node from that single source, so the whole cluster runs the same verified driver version.
  • Checksum on every load. Driver bytes are verified against a stored SHA-256 checksum before they load, so a corrupted or substituted binary is rejected rather than executed.
  • Controlled acquisition. When a driver is first needed and central acquisition is enabled, it is fetched once over an enforced HTTPS channel, checksum-verified, recorded to the configuration store, and thereafter served locally to the whole cluster.

The change is transparent to applications: existing connections behave as before, and the primary engines are unaffected because their drivers are bundled. What changes is the trust boundary. Driver provisioning is now an auditable, verified, cluster-consistent operation on the platform's control plane, not an unverified download on each node's boot path.

See the feature →

← All posts