Getting Started with Oracle NoSQL Database Cloud Service

Oracle NoSQL Database Cloud Service is a fully managed database cloud service that is designed for database operations that require predictable, single digit millisecond latency responses to simple queries.

NoSQL Database Cloud Service allows developers to focus on application development rather than setting up cluster servers, or performing system monitoring, tuning, diagnosing, and scaling. NoSQL Database Cloud Service is suitable for applications such as Internet of Things, user experience personalization, instant fraud detection, and online display advertising.

Once you are authenticated against your Oracle Cloud account, you can create a NoSQL table, and specify throughput and storage requirements for the table. Oracle reserves and manages the resources to meet your requirements, and provisions capacity for you. Capacity is specified using read and write units for throughput and GB for storage units.

This article has the following topics:

Quick Links

You can get started with Oracle NoSQL Database Service from one of the quick links below:

Table - Quick Links

     

Get Started

Connect

IDE and SDKs

Create Tables

Put and Explore Data

Manage Tables

Manage Security

Monitor the Service

Utilities

SQL Reference

Reference Guides

Setting up Your Service

If you're setting up Oracle NoSQL Database Cloud Service for the first time, follow these tasks as a guide.

Task Reference Related Information
Place an order for Oracle NoSQL Database Cloud Service or sign up for the Oracle Free Trial. Signing Up for Oracle Cloud Infrastructure in Oracle Cloud Infrastructure Documentation.

To learn how to estimate the monthly cost of your Oracle NoSQL Database Cloud Service subscription, see Estimating Your Monthly Cost .

To upgrade your free account or to change your payment method, see Changing Your Payment Method in Oracle Cloud Infrastructure Documentation.

Activate your Oracle Cloud account and sign in for the first time. Signing In to the Console in Oracle Cloud Infrastructure Documentation.

To familiarize yourself with Oracle Cloud Infrastructure Console, see Using the Console in Oracle Cloud Infrastructure Documentation.

(Recommended) Create a compartment for your service. Creating a Compartment

If you're not familiar with compartments, see Understanding Compartments in Oracle Cloud Infrastructure Documentation.

Manage security for your service. About Oracle NoSQL Database Cloud Service Security Model To familiarize yourself with NoSQL Database Cloud Service security model, see About Oracle NoSQL Database Cloud Service Security Model.

Accessing the Service from the Infrastructure Console

Learn how to access the Oracle NoSQL Database Cloud Service service from the Infrastructure Console.

  1. Locate the service URL from the welcome email, and then sign in to your Oracle NoSQL Database Cloud Service.
  2. Open the navigation menu, click Databases, and then click NoSQL Database.
  3. Select the compartment created for your tables by the service administrator.
To view help for the current page, click the help icon Help Drawer icon at the top of the page.

Creating a Compartment

When you sign up for Oracle Cloud Infrastructure, Oracle creates your tenancy with a root compartment that holds all your cloud resources. You then create additional compartments within the tenancy (root compartment) and corresponding policies to control access to the resources in each compartment. Before you create an Oracle NoSQL Database Cloud Service table, Oracle recommends that you set up the compartment where you want the table to belong.

You create compartments in Oracle Cloud Infrastructure Identity and Access Management (IAM). See Setting Up Your Tenancy and Managing Compartments in Oracle Cloud Infrastructure Documentation.

Authentication to connect to Oracle NoSQL Database

You need an Oracle Cloud account to connect your application to the Oracle NoSQL Database Cloud Service.

If you do not already have an Oracle Cloud account, you can start with Oracle Cloud. You need to authenticate yourself when you connect to the Oracle NoSQL Database. You could be authenticated using one of the following ways:

Authentication Method #1: User Principals

Here you use an OCI user and an API key for authentication. The credentials that are used for connecting your application are associated with a specific user. If you want to create a user for your application, see Setting Up Users, Groups, and Policies Using Identity and Access Management.

You can provide your credentials for this authentication method using one of the following ways:
  • Using a file on a local disk, The file contains details such as the user OCID, tenancy OCID, region, private key path, and fingerprint. You can use this if you are working from a secure network and storing private keys and configurations locally is in compliance with your security policies.
  • Supplying the credentials via an API.
  • Storing the credentials in a vault somewhere.

Information Comprising the Credentials:

Table - Credentials

What is it? Where to find it?
Tenancy ID and User ID ( Both are OCID ) See Where to Get the Tenancy's OCID and User's OCID in Oracle Cloud Infrastructure Documentation.
API Signing Key

For the application user, an API signing key must be generated and uploaded. If this has already been done this step can be skipped.

To know more, see the following resources in Oracle Cloud Infrastructure Documentation:
Fingerprint for the Signing Key and (Optional) Pass Phrase for the Signing Key The fingerprint and pass phrase of the signing key are created while generating and uploading the API Signing Key. See How to Get the Key's Fingerprint in Oracle Cloud Infrastructure Documentation.

Tip:

Make a note of the location of your private key, optional pass phrase, and fingerprint of the public key while generating and uploading the API Signing Key.

After performing the tasks discussed above, collect the credentials information and provide them to your application.

Providing the Credentials to your Application:

The Oracle NoSQL Database SDKs allow you to provide the credentials to an application in multiple ways. The SDKs support a configuration file as well as one or more interfaces that allow direct specification of the information. See the documentation for the programming language driver that you are using to know about the specific credentials interfaces.

If you are using a configuration file, the default location is ~/.oci/config. The SDKs allow the file to reside in alternative locations. It's content looks like this:
[DEFAULT]
user=ocid1.user.oc1..aaaaaaaas...7ap
fingerprint=d1:b2:32:53:d3:5f:cf:68:2d:6f:8b:5f:77:8f:07:13
key_file=~/.oci/oci_api_key_private.pem
tenancy=ocid1.tenancy.oc1..aaaaaaaap...keq
pass_phrase=mysecretphrase
The [DEFAULT] line indicates that the lines that follow specify the DEFAULT profile. A configuration file can include multiple profiles, prefixed with [PROFILE_NAME]. For example:
[DEFAULT]
user=ocid1.user.oc1..aaaaaaaas...7us
fingerprint=d1:b2:32:53:d3:5f:cf:68:2d:6f:8b:5f:77:8f:07:15
key_file=~/.oci/oci_api_key_private.pem
tenancy=ocid1.tenancy.oc1..aaaaabbap...keq
pass_phrase=mysecretphrase

[MYPROFILE]
user=ocid1.user.oc1..aaaaaaaas...7ap
fingerprint=d1:b2:32:53:d3:5f:cf:68:2d:6f:8b:5f:77:8f:07:13
key_file=~/.oci/oci_api_key_private.pem
tenancy=ocid1.tenancy.oc1..aaaaaaaap...keq
pass_phrase=mysecretphrase

Authentication Method #2: Instance Principals

Instance Principals is a capability in Oracle Cloud Infrastructure Identity and Access Management (IAM) that lets you make service calls from an instance. With instance principals, you don’t need to configure user credentials for the services running on your compute instances or rotate the credentials. Instances themselves are now a principal type in IAM. Each compute instance has its own identity, and it authenticates by using certificates that are added to the instance. These certificates are automatically created, assigned to instances, and rotated.

Using instance principals authentication, you can authorize an instance to make API calls on Oracle Cloud Infrastructure services. After you set up the required resources and policies, an application running on an instance can call Oracle Cloud Infrastructure public services, removing the need to configure user credentials or a configuration file. Instance principal authentication can be used from an instance where you don't want to store a configuration file.

Authentication Method #3: Resource Principals

You can use a resource principal to authenticate and access Oracle Cloud Infrastructure resources. The resource principal consists of a temporary session token and secure credentials that enable other Oracle Cloud services to authenticate themselves to Oracle NoSQL Database. Resource principal authentication is very similar to instance principal authentication, but is intended to be used for resources that are not instances, such as server-less functions.

A resource principal enables resources to be authorized to perform actions on Oracle Cloud Infrastructure services. Each resource has its own identity, and the resource authenticates using the certificates that are added to it. These certificates are automatically created, assigned to resources, and rotated, avoiding the need for you to create and manage your own credentials to access the resource. When you authenticate using a resource principal, you do not need to create and manage credentials to access Oracle Cloud Infrastructure resources.

Once authenticated, you need to be authorized to access the access Oracle Cloud Infrastructure resources. See Setting Up Users, Groups, and Policies Using Identity and Access Management for more details.

Authentication Method #4: Token-based Authentication:

Token-based authentication allows you to create and use a temporary session token to authenticate and access Oracle Cloud Infrastructure resources. Using token-based authentication, you create a local configuration file that contains information including the user OCID, tenancy OCID, region, private key path, and a temporary session token file path. This method uses this information along with the temporary session token, which expires in an hour (by default). Session token-based authentication can be used when you need quick, temporary authentication.

Creating a session token: You can generate a session token with or without using a web browser.

With a browser:

To use token-based authentication for the CLI on a computer with a web browser:
  1. In the terminal, run the following command:
    oci session authenticate
  2. Select a region.
  3. In the browser, enter your user credentials.
  4. After successful authentication, close the browser and follow the interactive prompt on the terminal. You need to provide the name of the profile you want to create in the config file. The new profile configuration gets written to the ~/.oci/config file. An example of the config file where the new profile ( for example TEST ) is updated is shown below.
    [TEST]
    user=<ocid1.user.oc1.........>
    fingerprint=<XX:XX:...........>
    key_file=<C:\Users\XXXXXX\.oci\oci_api_key_private.pem>
    tenancy=<ocid1.tenancy.oc1.....>
    region=us-ashburn-1
    security_token_file=<C:\Users\XXXXXX\.oci\sessions\TEST\token>

Without a browser:

To use token-based authentication for the CLI without a web browser, you must first authenticate using API key-based authentication.
oci setup config
This command prompts you for the information required to create the configuration file and the API public and private keys. The setup dialog uses this information to generate an API key pair and creates the configuration file. To use token-based authentication for the CLI without a web browser, run the following command:
oci session authenticate --no-browser
You need to provide the name of the profile you want to create in the config file. The new profile configuration gets written to the ~/.oci/config file. An example of the config file where the new profile ( for example TEST ) is updated is shown below.
[TEST]
user=<ocid1.user.oc1.........>
fingerprint=<XX:XX:...........>
key_file=<full_directory_path_oci_api_key_private.pem>
tenancy=<ocid1.tenancy.oc1.....>
region=us-ashburn-1
security_token_file=<full_directory_path_token>

Authentication Method #5: OKE Workload Identity-based Authentication:

The Oracle Container Engine for Kubernetes (OKE) Workload Identity provides fine-grained identity and access management control. A workload is an application running on Kubernetes. It can be comprised of a single component or several components that work together running inside a set of pods. A workload resource is identified by the unique combination of cluster, namespace, and service account. This unique combination is referred to as the workload identity. The OKE Workload Identity allows you to grant K8s pods policy-driven access to Oracle Cloud Infrastructure (OCI) resources using OCI Identity and Access Management (IAM).

With Workload Identity, you no longer need to store credentials as secrets in your Kubernetes cluster or rely on OCI dynamic groups for worker node policy-driven access to OCI resources and, more specifically, access to your NoSQL tables. When applications require access to OCI resources, Workload Identity enables you to write OCI IAM policies scoped to the Kubernetes service account associated with application pods. This feature allows the applications running inside these pods to directly access the OCI API based on the permissions provided by the policies.

To grant all the pods in a workload access to any OCI resource:
  • Create a namespace for a service account.
  • Create a service account for the application to use.
  • Define an IAM policy to grant the workload resource access to other OCI resources.
  • Download and configure the appropriate SDK for the language in which the application is written.
  • Edit the application to specify:
    • that workload requests are to be authenticated using the Kubernetes Engine workload identity provider
    • the OCI resources that are to be accessed
  • Update the application's deployment spec to specify that every pod in the workload is to use the service account.
Authorization to enable the workload to access the necessary OCI resources:
  • In the OCI Console, Open the navigation menu and click Identity & Security. Under Identity, click Policies.
  • Click Create Policy, and give the policy a name.
  • Enter a policy statement to enable the workload to access the necessary OCI resources, in the format shown below:
    Allow any-user to <verb> <resource> in <location> where all
    {
    request.principal.type = 'workload', 
    request.principal.namespace = '<namespace-name>', 
    request.principal.service_account = '<service-account-name>', 
    request.principal.cluster_id = '<cluster-ocid>'
    }
where:
  • <namespace-name> is the name of the namespace that you created previously.
  • <service-account-name> is the name of the service account that you created previously.
  • <cluster-ocid> is the cluster's OCID that you obtained previously.

Click Create to create the new policy.

Connecting your Application to NDCS

Learn how to connect your application to Oracle NoSQL Database Cloud Service.

Your application connects to Oracle NoSQL Database Cloud Service after being authenticated using one of the many methods available.

You can get yourself authenticated using one of the following:
  • API signing key
    • From any SDK (Java, Python, C#, GO, Node.js, Rust) program hard-coded directly
    • A configuration file with a default profile
    • A configuration file with a non-default profile
  • Instance Principals with Auth tokens
  • Resource Principals
  • Session-token
  • OKE Workload Identity

See Authentication to connect to Oracle NoSQL Database for more details on the authentication options.

You can connect to NDCS using one of the following methods:

  • Directly providing credentials in the code:
    /* Use the SignatureProvider to supply your credentials to NoSQL Database.
     * By default, the SignatureProvider will read your OCI configuration file 
     * from the default location, ~/.oci/config. See SignatureProvider for 
     * additional options for reading configurations in other ways.*/
    SignatureProvider sp = new SignatureProvider(
     tenantId,     // a string, OCID
     userId,       // a string, OCID
     fingerprint , // a string
     privateKey,   // a string, content of private key
     passPhrase    // optional, char[]
    );
    //Create an handle to access the cloud service in your service region.
    NoSQLHandleConfig config = new NoSQLHandleConfig(Region.<your-service-region>);
    config.setAuthorizationProvider(sp);
    NoSQLHandle handle = NoSQLHandleFactory.createNoSQLHandle(config);
    
    //At this point, your handle is set up to perform data operations. 
  • Connecting using the default configuration file with a default profile:
    /* Use the SignatureProvider to supply your credentials to NoSQL Database.
     * By default, the SignatureProvider will read your OCI configuration file 
     * from the default location, ~/.oci/config. See SignatureProvider for 
     * additional options for reading configurations in other ways. */
    SignatureProvider sp = new SignatureProvider();
  • Connecting using the default configuration file with non-default profile:
    /* Use the SignatureProvider to supply your credentials to NoSQL Database. 
    * Specify the name of the non-default profile in the construtor for SignatureProvider. 
    */
    final String profile_name = "<name_of_the_profile>";
    SignatureProvider sp = new SignatureProvider(profile_name);
  • Connecting using the specified configuration file and profile:
    /* Use the SignatureProvider to supply your credentials to NoSQL Database.
     * You specify the full path of the non-default config file and also the name 
     * of the profile
     */
    final String config_filepath = "<full_path_of_config_file>";
    final String profile_name = "<name_of_the_profile>";
    SignatureProvider sp = new SignatureProvider(config_filepath, profile_name);
  • Connecting using an Instance Principal :

    Instance Principal is an IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it.
    SignatureProvider authProvider = SignatureProvider.createWithInstancePrincipal();
  • Connecting using a Resource Principal :

    Resource Principal is an IAM service feature that enables the resources to be authorized actors (or principals) to perform actions on service resources.
    SignatureProvider authProvider = SignatureProvider.createWithResourcePrincipal();
  • Connecting using session-token:

    You use createWithSessionToken() method to create a SignatureProvider using a temporary session token read from a token file. The path of the token file is read from the default profile in the configuration file at the default location. The configuration file used is ~/.oci/config.
    SignatureProvider authProvider = 
    SignatureProvider.createWithSessionToken();
    You can also provide the path of the token file in the non-default profile in the configuration file as shown below. The path of the token file is read from the specified profile in the configuration file at the default location.
    SignatureProvider authProvider = 
    SignatureProvider.createWithSessionToken(<profile_name>);
  • Connecting using OKE Workload Identity:

    You can create a SignatureProvider with Container Engine for Kubernetes (OKE) workload identity using the Kubernetes service account token at the default path /var/run/secrets/kubernetes.io/serviceaccount/token. This provider can only be used inside Kubernetes pods.
    SignatureProvider authProvider = 
    SignatureProvider.createWithOkeWorkloadIdentity();
    You can also specify the specific Kubernetes service account token to be used as shown below.
    SignatureProvider authProvider = 
    SignatureProvider.createWithOkeWorkloadIdentity(<serviceAccountToken>);
    Alternatively, you can also specify the location of the specific Kubernetes service account token to be used as shown below.
    SignatureProvider authProvider = 
    SignatureProvider.createWithOkeWorkloadIdentity(<serviceAccountToken_location>);

See SignatureProvider for more details on the Java classes used.

You can connect to NDCS using one of the following methods:
  • Directly providing credentials in the code:
    from borneo.iam import SignatureProvider
    #
    # Use SignatureProvider directly via API. Note that the
    # private_key argument can either point to a key file or be the
    # string content of the private key itself.
    #
    at_provider = SignatureProvider(tenant_id='ocid1.tenancy.oc1..tenancy',
                                    user_id='ocid1.user.oc1..user',
                                    private_key=key_file_or_key, 
                                    fingerprint='fingerprint',   
                                    pass_phrase='mypassphrase')
  • Connecting using the default configuration file with a default profile:
    from borneo.iam import SignatureProvider
    #
    # Use SignatureProvider with a default credentials file and
    # profile in $HOME/.oci/config
    #
    at_provider = SignatureProvider()
  • Connecting using the specified configuration file with non-default profile:
    from borneo.iam import SignatureProvider
    #
    # Use SignatureProvider with a non-default credentials file and profile
    #
    at_provider = SignatureProvider(config_file='myconfigfile', 
                                    profile_name='myprofile')
  • Connecting using an Instance Principal:

    Instance Principal is an IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it.
    at_provider =
    SignatureProvider.create_with_instance_principal(region=my_region)
  • Connecting using a Resource Principal :

    Resource Principal is an IAM service feature that enables the resources to be authorized actors (or principals) to perform actions on service resources.
    at_provider = SignatureProvider.create_with_resource_principal()
  • Connecting using session-token:

    Borneo uses the OCI SDK for authentication using Session tokens. The OCI signer is passed as a parameter to the SignatureProvider constructor as shown below.
    from borneo.iam import SignatureProvider 
    # Use SignatureProvider with a provider argument which is an instance of  
    # oci.auth.signers.SecurityTokenSigner
    at_provider = SignatureProvider(<instance of oci.auth.signers.SecurityTokenSigner>)
  • Connecting using OKE Workload Identity:

    The OKE Workload Auth Signer is a signer that grants an entire workload (an application running on Kubernetes clusters) access to NoSQL tables using the OKE Workload Identity. It can be retrieved by oci.auth.signers.get_oke_workload_identity_resource_principal_signer. The retrieved signer can then be used when initializing a client.
    from borneo.iam import SignatureProvider
    oke_workload_signer = oci.auth.signers.get_oke_workload_identity_resource_principal_signer()
    If you have a Kubernetes service account token path different from the default path then you can specify the path as shown below:
    token_path = "path_to_your_token_file"
    oke_workload_signer  = oci.auth.signers.get_oke_workload_identity_resource_principal_signer(service_account_token_path=token_path)
    at_provider = SignatureProvider(oke_workload_signer)
    You can also directly pass the Kubernetes service account token as shown below:
    #token_string = "your_token_string"
    #oke_workload_signer = oci.auth.signers.get_oke_workload_identity_resource_principal_signer(service_account_token=token_string)
    at_provider = SignatureProvider(oke_workload_signer)
You can connect your application to NDCS using any of the following methods:
  • Directly providing credentials in the code:
    privateKeyFile := "/path/to/privateKeyFile"
    passphrase := "examplepassphrase"
    sp, err := iam.NewRawSignatureProvider("ocid1.tenancy.oc1..tenancy",
                                           "ocid1.user.oc1..user",
                                           "<your-service-region>", 
                                           "fingerprint", 
                                           "compartmentID", 
                                           privateKeyFile ,
                                           &passphrase )
    if err != nil {
        return
    }
    cfg := nosqldb.Config{
        AuthorizationProvider: sp,
        // This is only required if the "region" property is not 
        //specified in the config file.
        Region: "<your-service-region>",
    }
  • Connecting using the default configuration file with a default profile:
    cfg := nosqldb.Config{
    // This is only required if the "region" property is not 
    //specified in ~/.oci/config.
    // This takes precedence over the "region" property when both are specified.
        Region: "<your-service-region>", 
    }
    client, err := nosqldb.NewClient(cfg)
  • Connecting using the specified configuration file with non-default profile:
    sp, err := iam.NewSignatureProviderFromFile("your_config_file_path", 
               "your_profile_name", "", "compartment_id")
    if err != nil {
        return
    }
    cfg := nosqldb.Config{
        AuthorizationProvider: sp,
        // This is only required if the "region" property is not specified in the config file.
        Region: "us-ashburn-1",
    }
    client, err := nosqldb.NewClient(cfg)
  • Connecting using an Instance Principal:

    Instance Principal is an IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it.
    sp, err := iam.NewSignatureProviderWithInstancePrincipal("compartment_id")
    if err != nil {
        return
    }
    cfg := nosqldb.Config{
        AuthorizationProvider: sp,
        Region: "<your-service-region>",
    }
    client, err := nosqldb.NewClient(cfg)
  • Connecting using a Resource Principal :

    Resource Principal is an IAM service feature that enables the resources to be authorized actors (or principals) to perform actions on service resources.
    sp, err := iam.NewSignatureProviderWithResourcePrincipal("compartment_id")
    if err != nil {
        return
    }
    cfg := nosqldb.Config{
        AuthorizationProvider: sp,
        Region: "<your-service-region>",
    }
    client, err := nosqldb.NewClient(cfg)
  • Connecting using session-token:

    The NewSessionTokenSignatureProvider function creates a SignatureProvider using a temporary session token read from a token file.
    func NewSessionTokenSignatureProvider() (*SignatureProvider, error)

    The configuration file used is ~/.oci/config. The DEFAULT profile is used. The path of the token file is read from the configuration, using the value of the security_token_file field. When using this constructor, the user has a default compartment for all tables. It is the root compartment of the user's tenancy.

    To use a non-default config file (other than ~/.oci/config), you can use the function NewSessionTokenSignatureProviderFromFile.
    func NewSessionTokenSignatureProviderFromFile(configFilePath, 
    ociProfile, privateKeyPassphrase string) (*SignatureProvider, error)

    This function creates a SignatureProvider using a temporary session token read from a token file, using the ociProfile specified in the OCI configuration file configFilePath. The path of the token file is read from the configuration, using the value of the security_token_file field. The field privateKeyPassphrase is only required if the private key uses a passphrase and it is not specified in the pass_phrase field in the OCI configuration file. When using this constructor, the user has a default compartment for all tables. It is the root compartment of the user's tenancy.

  • Connecting using OKE Workload Identity:

    The Oracle NoSQL go SDK supports running programs inside OKE Workload containers in OCI. In your code that creates a SignatureProvider to use with NoSQL, add the following code to use the OKE Workload identity:
    conf, err := ociauth.OkeWorkloadIdentityConfigurationProvider()
    if err != nil {
       return nil, fmt.Errorf("cannot create an Oke Provider: %v", err)
    }
    myconf := &myConfigProvider{conf}
    sp, err := iam.NewSignatureProviderWithConfiguration(myconf, compartmentID)
    if err != nil {
      return nil, fmt.Errorf("cannot create a Signature Provider: %v", err)
    }
You can connect to NDCS using one of the following methods:
  • Directly providing credentials in the code:

    You may specify credentials directly as part of auth.iam property in the initial configuration. Create NoSQLClient instance as follows:
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    let client = new NoSQLClient({
        region: <your-service-region>
        auth: {
            iam: {
                tenantId: myTenancyOCID,
                userId: myUserOCID,
                fingerprint: myPublicKeyFingerprint,
                privateKeyFile: myPrivateKeyFile,
                passphrase: myPrivateKeyPassphrase
            }
        }
    });
  • Connecting using the default configuration file with a default profile:

    You can store the credentials in an Oracle Cloud Infrastructure configuration file. The default path for the configuration file is ~/.oci/config, where ~ stands for user's home directory. On Windows, ~ is a value of USERPROFILE environment variable. The file may contain multiple profiles. By default, the SDK uses profile named DEFAULT to store the credentials.

    To use these default values, create file named config in ~/.oci directory with the following contents:
    [DEFAULT]
    tenancy=<your-tenancy-ocid>
    user=<your-user-ocid>
    fingerprint=<fingerprint-of-your-public-key>
    key_file=<path-to-your-private-key-file>
    pass_phrase=<your-private-key-passphrase>
    region=<your-region-identifier>
    Note that you may also specify your region identifier together with credentials in the OCI configuration file. The driver will look at the location above by default, and if a region is provided together with credentials, you do not need to provide initial configuration and can use the no-argument constructor:
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    let client = new NoSQLClient();
    Alternatively, you may choose to specify the region in the configuration:
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    let client = new NoSQLClient({ region: Region.<your-service-region> });
  • Connecting using the specified configuration file with non-default profile:

    You may choose to use different path for OCI configuration file as well as different profile within the configuration file. In this case, specify these within auth.iam property of the initial configuration. For example, if your OCI configuration file path is ~/myapp/.oci/config and you store your credentials under profile Jane:

    Then create NoSQLClient instance as follows:
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    let client = new NoSQLClient({
        region: Region.<your-service-region>,
        auth: {
            iam: {
                configFile: '<your_config_file>',
                profileName: '<name_of_your_profile>'
            }
        }
    });
  • Connecting using an Instance Principal:

    Instance Principal is an IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it.

    Once set up, create NoSQLClient instance as follows:
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    const client = new NoSQLClient({
        region: Region.<your-service-region>,
        compartment: 'ocid1.compartment.oc1..............'
        auth: {
            iam: {
                useInstancePrincipal: true
            }
        }
    });
    You may also use JSON config file with the same configuration as described above. Note that when using Instance Principal you must specify compartment id (OCID) as compartment property. This is required even if you wish to use default compartment. Note that you must use compartment id and not compartment name or path. In addition, when using Instance Principal, you may not prefix table name with compartment name or path when calling NoSQLClient APIs.
  • Connecting using a Resource Principal :

    Resource Principal is an IAM service feature that enables the resources to be authorized actors (or principals) to perform actions on service resources.

    Once set up, create NoSQLClient instance as follows:
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    const client = new NoSQLClient({
        region: Region.<your-service-region>,
        compartment: 'ocid1.compartment.oc1...........................'
        auth: {
            iam: {
                useResourcePrincipal: true
            }
        }
    });
    You may also use JSON config file with the same configuration as described above. Note that when using Resource Principal you must specify compartment id (OCID) as compartment property. This is required even if you wish to use default compartment. Note that you must use compartment id and not compartment name or path. In addition, when using Resource Principal, you may not prefix table name with compartment name or path when calling NoSQLClient APIs.
  • Connecting using session-token:

    Using session-token-based authentication, you create a local configuration file that contains information including the user OCID, tenancy OCID, region, private key path, and a temporary session token file path.
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    const client = new NoSQLClient({
        region: Region.<your-service-region>,
        compartment: 'ocid1.compartment.oc1..............
       ' auth: {
           iam: { useSessionToken: true }  
      }
    }); 

    This method uses a temporary session token read from a token file. The path of the token file is read from the default profile in the OCI configuration file as the value of the security_token_file field.

    To use a non-default config file (other than ~/.oci/config), you can specify the path of the config file and the name of the profile as shown below.
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    const client = new NoSQLClient({
      region: Region.<your-service-region>,
      compartment: 'ocid1.compartment.oc1..............
      ' auth: {
        iam: {  useSessionToken: true,
          "configFile": "<path_to_config_file>",
          "profileName": "<profile_name>"
        }  
      }
    });
  • Connecting using OKE Workload Identity:

    The Oracle NoSQL Node.js SDK supports running programs inside OKE Workload containers in OCI.
    import { NoSQLClient, Region } from 'oracle-nosqldb';
    const client = new NoSQLClient({
        region: Region.<your-service-region>,
        compartment: 'ocid1.compartment.oc1...........................'
        ' auth: {
            iam: { useOKEWorkloadIdentity: true }
        }'
      }
    );
    This authorization scheme can only be used inside Kubernetes pods.Using OKE workload identity requires a service account token. By default, the provider will load the service account token from the default file path /var/run/secrets/kubernetes.io/serviceaccount/token . You may override this and provide your service account token by specifying one of 3 properties:
    • serviceAccountToken to provide a service account token string.
    • serviceAccountTokenFile to provide a path to the service account token file.
    • serviceAccountTokenProvider to provide a custom provider to load service account tokens.

See SDK Configuration File for details of the file's contents and format.

You can connect to NDCS using one of the following methods:
  • Directly providing credentials in the code:

    You may specify credentials directly as IAMCredentials when creating IAMAuthorizationProvider. Create NoSQLClient as follows:
    var client = new NoSQLClient(
        new NoSQLConfig
        {
            Region=<your-service-region>,
            AuthorizationProvider = new IAMAuthorizationProvider(
                new IAMCredentials
                {
                    TenantId=myTenancyOCID,
                    UserId=myUserOCID,
                    Fingerprint=myPublicKeyFingerprint,
                    PrivateKeyFile=myPrivateKeyFile
                })
        });
  • Connecting using the default configuration file with a default profile:

    You can store the credentials in an Oracle Cloud Infrastructure configuration file. The default path for the configuration file is ~/.oci/config, where ~ stands for user's home directory. On Windows, ~ is a value of USERPROFILE environment variable. The file may contain multiple profiles. By default, the SDK uses profile named DEFAULT to store the credentials

    To use these default values, create file named config in ~/.oci directory with the following contents:
    [DEFAULT]
    tenancy=<your-tenancy-ocid>
    user=<your-user-ocid>
    fingerprint=<fingerprint-of-your-public-key>
    key_file=<path-to-your-private-key-file>
    pass_phrase=<your-private-key-passphrase>
    region=<your-region-identifier>
    Note that you may also specify your region identifier together with credentials in the OCI configuration file. By default, the driver will look for credentials and a region in the OCI configuration file at the default path and in the default profile. Thus, if you provide region together with credentials as shown above, you can create NoSQLClient instance without passing any configuration:
    var client = new NoSQLClient();
    Alternatively, you may specify the region (as well as other properties) in NoSQLConfig:
    var client = new NoSQLClient(
        new NoSQLConfig(
        {
            Region = Region.<your-service-region>,
            Timeout = TimeSpan.FromSeconds(10),
        });
  • Connecting using the specified configuration file with non-default profile:

    You may choose to use different path for OCI configuration file as well as different profile within the configuration file. In this case, specify these within auth.iam property of the initial configuration. For example, if your OCI configuration file path is ~/myapp/.oci/config and you store your credentials under profile Jane:

    Then create NoSQLClient instance as follows:
    var client = new NoSQLClient(
        new NoSQLConfig
        {
            Region = Region.<your-service-region>,
            AuthorizationProvider = new IAMAuthorizationProvider(
                "<your_config_file>", "<your_profile_name>")
        });
  • Connecting using an Instance Principal:

    Instance Principal is an IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it. Once set up, create NoSQLClient instance as follows:
    var client = new NoSQLClient(
        new NoSQLConfig
        {
            Region=<your-service-region>,
            Compartment="ocid1.compartment.oc1.............................",
            AuthorizationProvider=IAMAuthorizationProvider.CreateWithInstancePrincipal()
        });
    You may also represent the same configuration in JSON as follows:
    {
        "Region": "<your-service-region>",
        "AuthorizationProvider":
        {
            "AuthorizationType": "IAM",
            "UseInstancePrincipal": true
        },
        "Compartment": "ocid1.compartment.oc1.............................",
    }

    Note that when using Instance Principal you must specify compartment id (OCID) as compartment property. This is required even if you wish to use default compartment. Note that you must use compartment id and not compartment name or path. In addition, when using Instance Principal, you may not prefix table name with compartment name or path when calling NoSQLClient APIs.

  • Connecting using a Resource Principal :

    Resource Principal is an IAM service feature that enables the resources to be authorized actors (or principals) to perform actions on service resources. Once set up, create NoSQLClient instance as follows:
    var client = new NoSQLClient(
        new NoSQLConfig
        {
            Region = <your-service-region>,
            Compartment =
                "ocid1.compartment.oc1.............................",
            AuthorizationProvider =
                IAMAuthorizationProvider.CreateWithResourcePrincipal()
        });
    You may also represent the same configuration in JSON as follows:
    {
        "Region": "<your-service-region>",
        "AuthorizationProvider":
        {
            "AuthorizationType": "IAM",
            "UseResourcePrincipal": true
        },
        "Compartment": "ocid1.compartment.oc1.............................",
    }

    Note that when using Resource Principal you must specify compartment id (OCID) as compartment property. This is required even if you wish to use default compartment. Note that you must use compartment id and not compartment name or path. In addition, when using Resource Principal, you may not prefix table name with compartment name or path when calling NoSQLClient APIs.

  • Connecting using session-token:

    Using session-token-based authentication, you create a local configuration file that contains information including the user OCID, tenancy OCID, region, private key path, and a temporary session token file path.

    You can use the session-token-based authentication using one of the three methods as shown below.

    Option 1: This creates a new instance of IAMAuthorizationProvider using session token-based authentication with the default OCI configuration file and the default profile name.
    var client = new NoSQLClient(
    new NoSQLConfig {
       Region = <your-service-region>,
       Compartment = "ocid1.compartment.oc1.............................",
       AuthorizationProvider = IAMAuthorizationProvider.CreateWithSessionToken()
    });
    Option 2: This creates a new instance of IAMAuthorizationProvider using session token-based authentication with the default OCI configuration file and the specified profile name.
    var client = new NoSQLClient(
    new NoSQLConfig {
       Region = <your-service-region>,
       Compartment = "ocid1.compartment.oc1.............................",
       AuthorizationProvider = IAMAuthorizationProvider.CreateWithSessionToken(<profileName>)
    });
    Option 3: This creates a new instance of IAMAuthorizationProvider using session token-based authentication with the specified OCI configuration file and profile name.
    var client = new NoSQLClient(
    new NoSQLConfig {
       Region = <your-service-region>,
       Compartment = "ocid1.compartment.oc1.............................",
       AuthorizationProvider = IAMAuthorizationProvider.CreateWithSessionToken(<configFile>,<profileName>)
    });
    You may also represent the same configuration in JSON as follows:
    {
      "Region": "<your-service-region>",
      "AuthorizationProvider": {
        "AuthorizationType": "IAM",
        "UseSessionToken": true
      },
      "Compartment": "ocid1.compartment.oc1............................."
    }
  • Connecting using OKE Workload Identity:

    The Oracle NoSQL Dotnet SDK supports running programs inside OKE Workload containers in OCI.

    The example below creates a new instance of IAMAuthorizationProvider using OKE workload identity. This method allows you to specify an optional service account token string. If not specified, the service account token will be read from the default file path /var/run/secrets/kubernetes.io/serviceaccount/token.
    var client = new NoSQLClient(
    new NoSQLConfig {
       Region = <your-service-region>,
       Compartment = "ocid1.compartment.oc1.............................",
       AuthorizationProvider = IAMAuthorizationProvider.CreateWithOKEWorkloadIdentity()
    });
    You can also create a new instance of IAMAuthorizationProvider using OKE workload identity and specified service account token file as shown below.
    var client = new NoSQLClient(
    new NoSQLConfig {
       Region = <your-service-region>,
       Compartment = "ocid1.compartment.oc1.............................",
       AuthorizationProvider = 
        IAMAuthorizationProvider.CreateWithOKEWorkloadIdentityAndTokenFile(<serviceAccountTokenFile>)
    });
    You may also represent the same configuration in JSON as follows:
    { "Region": "<your-service-region>",  
     "AuthorizationProvider":  {
       "AuthorizationType": "IAM",
       "UseOKEWorkLoadIdentity": true 
     },
     "Compartment": "ocid1.compartment.oc1.............................",
    }
You can connect to NDCS using one of the following methods:
  • Connecting using the default configuration file with a default profile:

    You can store the credentials in an Oracle Cloud Infrastructure configuration file. The default path for the configuration file is ~/.oci/config, where ~ stands for user's home directory. On Windows, ~ is a value of USERPROFILE environment variable. The file may contain multiple profiles. By default, the SDK uses profile named DEFAULT to store the credentials

    To use these default values, create file named config in ~/.oci directory with the following contents:
    [DEFAULT]
    tenancy=<your-tenancy-ocid>
    user=<your-user-ocid>
    fingerprint=<fingerprint-of-your-public-key>
    key_file=<path-to-your-private-key-file>
    pass_phrase=<your-private-key-passphrase>
    region=<your-region-identifier>

    Note that you may also specify your region identifier together with credentials in the OCI configuration file. By default, the driver will look for credentials and a region in the OCI configuration file at the default path and in the default profile. The region is only required if HandleBuilder::cloud_region() is not used. The pass_phrase is only required if the RSA key file requires one.

    The first step in any Oracle NoSQL Database Cloud Service Rust application is to create a Handle used to send requests to the service, based on the configuration given in a HandleBuilder struct. Instances of the Handle are safe for concurrent use and intended to be shared in a multi-threaded or asynchronous application. The following code example shows how to connect to the cloud service, using a user config file:
    let handle = Handle::builder()
    .cloud_auth_from_file("~/.oci/config")?
    .build().await?;
  • Connecting using an Instance Principal

    Instance Principal is an IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it. To configure NoSQL in this mode, use the following code:
    let handle = Handle::builder()
    .cloud_auth_from_instance()?
    .build().await?;
  • Connecting using a Resource Principal

    Resource Principal is an IAM service feature that enables the resources to be authorized actors (or principals) to perform actions on service resources. To configure NoSQL in this mode, use the following code:
    let handle = Handle::builder()
    .cloud_auth_from_resource()?
    .build().await?;

Typical Workflow

Typical sequence of tasks to work with Oracle NoSQL Database Cloud Service.

If you're developing applications using Oracle NoSQL Database Cloud Service for the first time, follow these tasks as a guide.

Task Description More Information
Connect your application Connect your application to use Oracle NoSQL Database Cloud Service tables. Connecting your Application to NDCS
Develop your application Develop your application after connecting to Oracle NoSQL Database Cloud Service tables. Developing in Oracle Cloud

Developing in Oracle NoSQL Database Cloud Simulator

If you're setting up Oracle NoSQL Database Cloud Service for the first time, see Setting up Your Service.

Quick Start Tutorials

Access the quick start tutorials and get started with the service.

  1. Get access to the service.

    Sign up for a Cloud promotion or purchase an Oracle Cloud subscription. Activate your order, create users (optional). See Setting up Your Service.

  2. Acquire credentials to connect your application. See Authentication to connect to Oracle NoSQL Database.

  3. Create a table in Oracle NoSQL Database Cloud Service.