New and changed in Vertica 24.2

• 1: Backup and restore
• 2: Client connectivity
• 3: Client drivers
• 4: Configuration
• 5: Containers and Kubernetes
• 6: Data load
• 7: Database management
• 8: Machine learning
• 9: Security and authentication
• 10: Stored procedures

1 - Backup and restore

vbr target namespace creation

For vbr restore and replicate tasks, if the namespace specified in the --target-namespace parameter does not exist in the target database, vbr creates a namespace with the name specified in --target-namespace and the shard count of the source namespace, and then replicates or restores the objects to that namespace. See Eon Mode database requirements for details.

2 - Client connectivity

Add and remove subclusters from routing rules

You can now alter a routing rule to add or remove subclusters. For details, see ALTER ROUTING RULE.

3 - Client drivers

OAuth support for ADO.NET

You can now use OAuth to connect to Vertica with ADO.NET.

The ADO.NET driver uses a simplified configuration scheme and takes a single connection property: an access token retrieved by the client from the identity provider. Other flows like token refresh should be handled externally by the driver.

The JDBC and ODBC drivers will follow a similar configuration scheme in future versions.

For details on OAuth, see OAuth 2.0 authentication.

4 - Configuration

S3

Vertica now supports S3 access through a proxy. See the S3Proxy configuration parameter and the proxy field in S3BucketConfig.

5 - Containers and Kubernetes

AWS Secrets Manager support

The VerticaDB operator can access secrets that you store in Amazon Web Service's AWS Secrets Manager. This lets you maintain a single location for all sensitive information that you share between AWS and Vertica on Kubernetes.

For details, see Secrets management.

VerticaRestorePointsQuery custom resource definition

The VerticaRestorePointsQuery custom resource definition (CRD) retrieves restore points from an archive so that you can restore objects or roll back your database to a previous state. The custom resource (CR) specifies an archive and an optional period of time, and the VerticaDB operator retrieves restore points saved to the archive.

For details, see VerticaRestorePointsQuery custom resource definition and Custom resource definition parameters.

VerticaDB CRD parameters

The VerticaDB custom resource definition provides the following CRD parameters to revive from a restore point:

• restorePoint.archive
• restorePoint.id
• restorePoint.index

You can use the VerticaRestorePointsQuery custom resource definition to retrieve saved restore points. For details about the CRD parameters, see Custom resource definition parameters.

VerticaScrutinize custom resource definition

The VerticaScrutinize CRD runs scrutinize to collect diagnostic information about a VerticaDB CR. Vertica support might request you provide this diagnostic information while resolving support cases.

For details, see VerticaScrutinize custom resource definition.

Namespace-scoped operators

You can use Helm charts to deploy the VerticaDB operator to watch only resources within a namespace. This requires that you set the following Helm chart parameters during installation:

• controllers.enable
• controllers.scope

For installation instructions, see Installing the VerticaDB operator. For details about each parameter, see Helm chart parameters.

Node Management Agent (NMA) sidecar

Vertica on Kubernetes runs the Node Management Agent in a sidecar container. The NMA exposes a REST API the VerticaDB operator uses to administer a cluster.

For details, see Containerized Vertica on Kubernetes.

Support OpenShift restricted-v2 SCC

Vertica on Kubernetes supports the restricted-v2 SCC for OpenShift. This is the most restrictive SCC available.

For details about the Vertica and OpenShift integration, see Red Hat OpenShift integration.

Namespace-scoped operators

You can use Helm charts to deploy the VerticaDB operator to watch only resources within a namespace. This requires that you set the following Helm chart parameters during installation:

• controllers.enable
• controllers.scope

For installation instructions, see Installing the VerticaDB operator. For details about each parameter, see Helm chart parameters.

Containerized Kafka Scheduler

Vertica on Kubernetes supports the Kafka scheduler, a mechanism that automatically loads data from Kafka into a Vertica database table. Vertica packages the scheduler in a Helm chart so you can easily deploy a scheduler into your Kubernetes environment.

For details, see Containerized Kafka Scheduler.

6 - Data load

Automatic load triggers from AWS

Data loaders can process messages from SQS (Simple Queue Service) queues on AWS to load new files that are added to an S3 bucket. You define a trigger when creating the data loader, and Vertica automatically runs EXECUTE DATA LOADER in response to events in the queue.

Iceberg version 2

CREATE EXTERNAL TABLE ICEBERG supports both version 1 and version 2 of the metadata format.

7 - Database management

HTTPS service

For details on the HTTPS service, see HTTPS service.

View client connections

You can now use the /v1/node/connections endpoint to view the number of client connections to that node.

The following example shows that there are 11 total connections to the node at 127.0.0.1, 2 of which are just starting to initialize:

$ curl -sk -w "\n" --user dbadmin: "https://127.0.0.1:8443/v1/node/connections"
{
  "total_connections": 11,
  "user_sessions": 9,
  "initializing_connections": 2
} 

Drain subclusters

You can now use the /v1/subclusters/subcluster_name/drain endpoint to drain connections from a subcluster. This functionality was previously limited to the SHUTDOWN_WITH_DRAIN function. To verify the draining status of your subclusters, query DRAINING_STATUS.

To drain the connections from a subcluster, you can send a POST request with one of the following:

• An empty body
• {"cancel": false}

For example:

$ curl -i -X POST -d '{"cancel": false}' -ks -w "\n" --user dbadmin: https://127.0.0.1:8443/v1/subclusters/sc_01/drain
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 43
Connection: keep-alive
Server: oatpp/1.3.0 

To stop draining connections, send a POST request with {"cancel": true}. For example:

$ curl -i -X POST -d '{"cancel": true}' -ks -w "\n" --user dbadmin: https://127.0.0.1:8443/v1/subclusters/sc_01/drain
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 47
Connection: keep-alive
Server: oatpp/1.3.0

View subscription states

The new /v1/subscriptions endpoint returns information on a node's subscriptions to shards:

• node_name
• shard_name: The shard the node is subscribed to
• subscription_state: Subscription status (ACTIVE, PENDING, PASSIVE, or REMOVING)
• is_primary: Whether the subscription is a primary subscription

For example:

$ curl -i -sk -w "\n" --user dbadmin:my_password "https://127.0.0.1:8443/v1/subscriptions"

{
  "subscriptions_list":
   [
    {
      "node_name": "node08",
      "shard_name": "segment0004",
      "subscription_state": "ACTIVE",
      "is_primary": false
    },
    ...
  ]
} 

Depot and data paths

The following storage locations fields have been added to the /v1/nodes and /v1/nodes/node_name endpoints:

• data_path: A list of paths used to store USAGE 'DATA,TEMP' data.
• depot_path: The path used to store USAGE 'DEPOT' data.

For example:

$ curl -i -sk --user dbadmin:my_password https://127.0.0.1:8443/v1/nodes
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 648
Connection: keep-alive
Server: oatpp/1.3.0

{
  "detail": null,
  "node_list": [
    {
      "name": "v_vmart_node0001",
      "node_id": 45035996273704982,
      "address": "192.0.2.0",
      "state": "UP",
      "database": "VMart",
      "is_primary": true,
      "is_readonly": false,
      "catalog_path": "\/scratch_b\/VMart\/v_vmart_node0001_catalog\/Catalog",
      "data_path": [
        "\/scratch_b\/VMart\/v_vmart_node0001_data"
      ],
      "depot_path": "\/scratch_b\/VMart/my_depot",
      "subcluster_name": "",
      "last_msg_from_node_at": "2023-12-01T12:38:37.009443",
      "down_since": null,
      "build_info": "v24.1.0-20231126-36ee8c3de77d43c6ad7bbef252302977952ac9d6"
    }
  ]
}

$ curl -i -sk --user dbadmin:my_password https://127.0.0.1:8443/v1/nodes/v_vmart_node0001/
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 648
Connection: keep-alive
Server: oatpp/1.3.0

{
  "detail": null,
  "node_list": [
    {
      "name": "v_vmart_node0001",
      "node_id": 45035996273704982,
      "address": "192.0.2.0",
      "state": "UP",
      "database": "VMart",
      "is_primary": true,
      "is_readonly": false,
      "catalog_path": "\/scratch_b\/VMart\/v_vmart_node0001_catalog\/Catalog",
      "data_path": [
        "\/scratch_b\/VMart\/v_vmart_node0001_data"
      ],
      "depot_path": "\/scratch_b\/VMart/my_depot",
      "subcluster_name": "",
      "last_msg_from_node_at": "2023-12-01T12:38:37.009443",
      "down_since": null,
      "build_info": "v24.1.0-20231126-36ee8c3de77d43c6ad7bbef252302977952ac9d6"
    }
  ]
}

8 - Machine learning

Partial least squares (PLS) regression support

Vertica now supports PLS regression models.

Combining aspects of PCA (principal component analysis) and linear regression, the PLS regression algorithm extracts a set of latent components that explain as much covariance as possible between the predictor and response variables, and then performs a regression that predicts response values using the extracted components.

This technique is particularly useful when the number of predictor variables is greater than the number of observations or the predictor variables are highly collinear. If either of these conditions is true of the input relation, ordinary linear regression fails to converge to an accurate model.

The PLS_REG function creates and trains a PLS model, and the PREDICT_PLS_REG function makes predictions on an input relation using a PLS model. For an in-depth example, see PLS regression.

Vector autoregression (VAR) support

Vertica now supports VAR models.

VAR is a multivariate autoregressive time series algorithm that captures the relationship between multiple time series variables over time. Unlike AR, which only considers a single variable, VAR models incorporate feedback between different variables in the model, enabling the model to analyze how variables interact across lagged time steps. For example, with two variables—atmospheric pressure and rain accumulation—a VAR model could determine whether a drop in pressure tends to result in rain at a future date.

The AUTOREGRESSOR function automatically executes the algorithm that fits your input data:

• One value column: the function executes autoregression and returns a trained AR model.
• Multiple value columns: the function executes vector autoregression and returns a trained VAR model.

To make predictions with a VAR model, use the PREDICT_AUTOREGRESSOR function. See VAR model example for an extended example.

9 - Security and authentication

OAuth2 security configuration parameters

There are new security configuration parameters that provide more control for users created with just-in-time (JIT) provisioning:

• OAuth2JITRolesClaimName: Identifies an IdP role claim. JIT-provisioned users are automatically assigned the claim roles as default roles. This parameter replaces OAuth2JITClient.
• OAuth2JITGroupsClaimName: Identifies an IdP group claim. JIT-provisioned users are automatically assigned the group claim name or group claim roles as default roles.
• OAuth2JITForbiddenRoles: Restricts the specified roles during automatic role assignment.

For details, see Security parameters

OAuth authentication parameters

Vertica provides the following OAuth authentication parameters that configure an OAuth authentication record that uses JIT provisioning:

• groups_claim_name
• oauth2_jit_authorized_roles
• role_group_suffix
• roles_claim_name

For details about each parameter, see OAuth authentication parameters.

Automatic role assignment for JWT validation

Vertica supports automatic role assignment for just-in-time provisioned (JIT) users that use authentication records with the JWT validation type.

For details, see Just-in-time user provisioning.

Fixed schedules for LDAP Link

The LDAP Link service now supports fixed schedules with LDAPLinkCron. This acts as an alternative to LDAPLinkInterval.

LDAPLinkInterval calculates the time of the next synchronization based on the completion time of the last synchronization. For example, suppose LDAPLinkInterval is set to 24 hours. If synchronization starts at 9:00 AM and finishes in 30 minutes, the next synchronization will occur at 9:30 AM the next day.

The new LDAPLinkCron parameter lets you designate an exact time for the synchronization with a cron expression so that the completion time doesn't affect the next runtime. Value separators are not currently supported.

For details, see LDAP link parameters.

For example, to run the LDAP Link synchronization operation on the second day of every month at 7:00 PM:

=> ALTER DATABASE DEFAULT SET LDAPLinkCron='0 19 */2 * *';

10 - Stored procedures

Schedule steps and ranges

Schedules now support cron expressions that use steps and ranges. For details, see Scheduled execution.