Category
Data Management
1. Introduction
Oracle Cloud NoSQL Database is a fully managed, schema-flexible database service designed for applications that need predictable low latency, elastic throughput, and simple key-value or document-style access patterns without operating database servers.
In simple terms: you create a table, define a primary key, choose how much read/write capacity you want, and then your application reads/writes data using SDKs, APIs, or query statements—while Oracle Cloud Infrastructure (OCI) handles patching, scaling (within chosen limits), and high availability.
Technically, NoSQL Database in Oracle Cloud (often referred to in Oracle documentation as Oracle NoSQL Database Cloud Service) is a managed NoSQL datastore built around tables, primary/shard keys, optional secondary indexes, and a SQL-like query language for working with structured and semi-structured data. It integrates with core OCI controls such as IAM policies, compartments, Audit, and Monitoring.
The main problem it solves is: storing and retrieving high-volume operational data with predictable performance (for example, user sessions, device telemetry, shopping carts, profiles, feature flags, and event metadata) without the operational overhead of running and scaling a database cluster yourself.
2. What is NoSQL Database?
Official purpose
Oracle Cloud NoSQL Database is OCI’s managed NoSQL offering for building modern applications that need: – Low-latency reads/writes – Horizontal scalability through partitioning/sharding – Flexible data modeling (records/rows can contain nested JSON-like structures depending on API usage) – Managed operations with OCI-native governance
You’ll see the service referenced as NoSQL Database in the OCI Console, while Oracle marketing and documentation may use Oracle NoSQL Database Cloud Service. Treat these as the same OCI service; verify naming in the latest OCI Console and docs for your region.
Core capabilities (what it does)
- Create and manage NoSQL tables
- Insert, update, retrieve, delete records by key
- Query records using a SQL-like query language (capabilities depend on API/SDK)
- Configure capacity/limits (read units, write units, storage) as supported by the service
- Add secondary indexes for additional query patterns (where supported)
- Apply time-to-live (TTL) patterns (where supported) for automatic expiry
Major components
- Tenancy: Your OCI account boundary.
- Region: NoSQL Database resources are created in an OCI region.
- Compartment: Resource organization and access control boundary.
- Table: Primary data container.
- Primary key / shard key: Determines uniqueness and distribution.
- Indexes: Optional, to support non-key query patterns (verify supported index types in official docs).
- SDK/CLI/API: Application access methods (Java, Python, Node.js, Go, REST—availability varies; verify in official SDK docs).
Service type
- Fully managed NoSQL database service (managed control plane and data plane).
- Typically used as an operational database (OLTP-style access patterns), not as an analytics warehouse.
Scope: regional/global/zonal and account/project boundaries
- Regional: Tables are created in a specific OCI region.
- Tenancy-scoped governance: Access is controlled through OCI IAM at tenancy/compartment scope.
- Compartment-scoped resources: Tables live in compartments for lifecycle and policy control.
How it fits into the Oracle Cloud ecosystem
NoSQL Database is part of OCI’s Data Management portfolio and commonly integrates with: – OCI IAM for authentication/authorization – OCI Monitoring for metrics and alarms – OCI Audit for recording administrative API calls – VCNs + Service Gateway to access OCI services privately from private subnets (where applicable) – OCI Functions, API Gateway, Container Engine for Kubernetes (OKE), and compute instances for application runtimes – OCI Streaming and Object Storage for event ingestion and archival patterns (integration often implemented at the application layer; verify official reference architectures)
3. Why use NoSQL Database?
Business reasons
- Faster time-to-market: reduce operational burden (no cluster management, patching, or replication setup handled by your team).
- Predictable performance for customer-facing apps (low-latency reads/writes matter more than complex joins).
- Better alignment of cost with throughput demand (capacity-based pricing is common; confirm the model for your region).
Technical reasons
- Fits key-value/document workloads naturally (session state, profiles, IoT device state).
- Encourages application-driven data modeling (denormalized, query-by-access-pattern).
- Supports very high request rates with low latency when keys are well-designed and capacity is correctly provisioned.
Operational reasons
- Managed HA characteristics (service handles infrastructure redundancy within the region—verify details in official docs).
- Tight OCI integration: compartments, IAM policies, tags, audit trails, and monitoring.
Security/compliance reasons
- Integrates with OCI IAM policies and compartments for least-privilege access.
- Uses encryption controls expected of OCI managed services (at-rest and in-transit; verify specifics in the security documentation).
- OCI Audit provides governance visibility for administrative actions.
Scalability/performance reasons
- Designed for horizontal scaling using shard/partition keys.
- Predictable latency for key-based operations.
- Capacity controls allow you to plan throughput and reduce “noisy neighbor” effects.
When teams should choose it
Choose Oracle Cloud NoSQL Database when: – Your access patterns are known and mostly key-based. – You need low latency and high throughput at scale. – You want a managed NoSQL service integrated with OCI governance. – You can design a good shard/partition key and avoid heavy cross-partition queries.
When teams should not choose it
Avoid (or re-check fit) if: – You need complex relational joins, multi-table transactions, or ad hoc analytics queries (consider Oracle Autonomous Database). – Your query patterns are unpredictable and require flexible multi-field querying without careful indexing. – You need advanced full-text search (consider a search service or OpenSearch/Elasticsearch patterns). – You require multi-region active-active behavior and can’t confirm NoSQL Database supports it for your use case (verify in official docs).
4. Where is NoSQL Database used?
Industries
- Retail/e-commerce: carts, product personalization, sessions
- Financial services: user/device state, fraud feature lookups (not typically system of record ledgers)
- Gaming: player profiles, inventory, matchmaking metadata
- Telecom: subscriber/device state and configuration
- SaaS: tenant metadata, feature flags, rate-limiting counters
- IoT/manufacturing: device telemetry pointers, digital twin state snapshots
Team types
- Application developers building APIs and microservices
- Platform teams standardizing operational datastores
- DevOps/SRE teams needing managed services with strong IAM/monitoring
- Security teams needing compartment-based governance and auditability
Workloads
- High-volume OLTP-style workloads (reads/writes by key)
- Event metadata storage (store pointers/aggregates; keep bulk events in Object Storage)
- User state/session storage
- Configuration and feature flagging
Architectures
- Microservices on OKE or Compute calling NoSQL Database directly via SDK
- API Gateway → Functions → NoSQL Database for serverless APIs
- Streaming ingestion pipelines where consumers write state to NoSQL Database
Real-world deployment contexts
- Production: capacity provisioned based on SLOs, alarms on throttling, strong IAM controls, and private networking patterns where feasible
- Dev/test: smaller table limits, shorter TTLs, ephemeral environments and automated cleanup
5. Top Use Cases and Scenarios
Below are realistic scenarios where Oracle Cloud NoSQL Database is commonly a strong fit. Each assumes you model data around access patterns and keys.
-
User Session Store – Problem: Maintain login sessions and refresh tokens with fast lookups. – Why this fits: Key-based reads/writes with predictable latency; TTL patterns can expire sessions automatically (verify TTL support). – Example:
sessionIdas shard key; store userId, issuedAt, scopes. -
Shopping Cart Service – Problem: Persist carts reliably during user browsing spikes. – Why this fits: High write/read throughput during peak traffic; schema flexibility for cart items. – Example: Key by
(tenantId, userId); record contains item list and pricing snapshot. -
Device Digital Twin State – Problem: Track the latest known state of millions of devices. – Why this fits: “Last write wins” state updates are common; reads are by deviceId. – Example:
deviceIdshard key; store lastSeen, firmware, desiredConfig. -
Feature Flags and Remote Config – Problem: Serve configuration at runtime with very low latency. – Why this fits: Frequent reads, occasional writes; low operational overhead. – Example: Key by
(appId, flagName); store rules and rollout percentages. -
Rate Limiting / Quota Counters – Problem: Enforce API quotas per tenant/user in near real time. – Why this fits: Simple get/update patterns; can be implemented with atomic update patterns (verify transaction/atomic features). – Example: Key by
(tenantId, windowStart); store counters per API. -
User Profile and Preferences – Problem: Store semi-structured preferences that evolve frequently. – Why this fits: Flexible schema; low-latency reads for personalization. – Example: Key by
userId; record contains notification settings, UI preferences. -
Order Status Read Model (CQRS) – Problem: Fast read model for order tracking, separate from write-heavy order system. – Why this fits: Denormalized read model; optimized for key and time-range patterns (index/time modeling required). – Example: Key by
(customerId, orderId); record contains current state and last update. -
Metadata Store for Object Storage / Data Lake – Problem: Maintain metadata for files/events stored in Object Storage. – Why this fits: Fast metadata lookups; bulk payload stays in cheaper storage. – Example: Key by
(datasetId, objectName); store schema version, tags, checksums. -
Multi-tenant SaaS Tenant Registry – Problem: Track tenant settings, plan, limits, routing. – Why this fits: Strong key lookups, predictable latency for every request. – Example: Key by
tenantId; store planTier, region, feature entitlements. -
Idempotency Key Store – Problem: Prevent duplicate processing of API requests. – Why this fits: Key existence checks and conditional writes (verify conditional put support). – Example: Key by
(tenantId, idempotencyKey); store request hash and response pointer. -
Leaderboard Snapshot Cache – Problem: Serve precomputed leaderboard segments quickly. – Why this fits: Hot reads, periodic batch writes. – Example: Key by
(gameId, seasonId, segment); store top N scores. -
Edge/Regional Cache Backing Store – Problem: Provide a durable, fast store behind regional caches. – Why this fits: Predictable throughput; simple data model; durability within the region. – Example: Key by cacheKey; store payload and expiry metadata.
6. Core Features
Feature availability can vary by region, API type, or service version. Always verify in the official OCI NoSQL Database documentation.
6.1 Managed tables with capacity/limits
- What it does: Lets you create tables and define throughput and storage limits (commonly read units, write units, and storage in GB).
- Why it matters: Predictable performance and cost; prevents runaway consumption.
- Practical benefit: You can set a low-cost dev table and a larger production table aligned to SLOs.
- Caveat: Mis-sized capacity can cause throttling or higher cost. Monitor and adjust.
6.2 Primary key + shard/partition key modeling
- What it does: Uses a primary key (often including a shard/partition key) to distribute data and route requests efficiently.
- Why it matters: Key design is the biggest determinant of performance and scalability.
- Practical benefit: Even distribution avoids hot partitions; consistent low latency.
- Caveat: Poor shard key choice can create hot spots and throttling.
6.3 SQL-like query language (NoSQL query)
- What it does: Enables selecting and filtering records beyond simple key gets, depending on indexes and supported query features.
- Why it matters: Reduces the need for external query engines for common operational queries.
- Practical benefit: You can build admin screens and API list endpoints.
- Caveat: Non-key queries can be expensive and may require indexing; avoid unbounded scans in production.
6.4 Secondary indexes (where supported)
- What it does: Adds indexes on non-primary-key fields to support additional query patterns.
- Why it matters: Enables efficient lookups by attributes (email, status, timestamps).
- Practical benefit: Faster queries without full table scans.
- Caveat: Indexes add write overhead and can increase storage consumption.
6.5 JSON/semi-structured record support (API-dependent)
- What it does: Allows records to contain nested structures (commonly via SDK types or JSON payload fields).
- Why it matters: Supports evolving schemas and flexible attributes.
- Practical benefit: Add new fields without heavyweight migrations.
- Caveat: Uncontrolled schema growth can create operational complexity and unpredictable query costs.
6.6 Consistency options (service/SDK dependent)
- What it does: Many NoSQL systems offer tuning between latency and consistency (for example eventual vs strong/absolute reads).
- Why it matters: Some workloads (auth/session validation) may require stronger consistency guarantees.
- Practical benefit: Choose the right tradeoff per call.
- Caveat: Stronger consistency can increase latency and cost.
6.7 TTL and data lifecycle controls (where supported)
- What it does: Automatically expires records after a defined period.
- Why it matters: Prevents unbounded growth for ephemeral datasets (sessions, idempotency keys).
- Practical benefit: Lower storage cost and simpler cleanup.
- Caveat: TTL behavior and granularity should be validated; do not assume hard real-time deletion.
6.8 OCI-native governance: compartments, tags, IAM
- What it does: Uses OCI compartments and IAM policies to control who can manage tables and access data.
- Why it matters: Enterprise-grade separation of duties and least privilege.
- Practical benefit: Separate dev/test/prod compartments; use tags for cost allocation.
- Caveat: Over-broad policies are a common security mistake.
6.9 Observability via OCI Monitoring and Audit
- What it does: Publishes metrics for performance/capacity and emits audit logs for API operations.
- Why it matters: You need to detect throttling, errors, or unexpected activity.
- Practical benefit: Alerts when consumption approaches provisioned limits.
- Caveat: Application-level tracing/logging still needs to be implemented by you.
7. Architecture and How It Works
High-level service architecture
At a high level: – Your application authenticates using OCI IAM (user principals, instance principals, workload identity, etc.). – The application calls NoSQL Database endpoints in a region using SDK/CLI/REST. – The service routes requests based on table and key/shard design. – Metrics and audit events are emitted to OCI Monitoring and OCI Audit.
Request/data/control flow
- Control plane: Create/update/delete tables, manage limits/capacity, define indexes. This is typically done via Console/CLI/API and recorded in OCI Audit.
- Data plane: Read/write/query operations performed by applications via SDK or REST. Your application must handle retries/backoff for throttling or transient issues.
Integrations with related services (common patterns)
- Compute / OKE / Functions: Run microservices that call NoSQL Database.
- API Gateway: Front-door for REST APIs; backends call NoSQL Database.
- VCN + Service Gateway: Keep traffic from private subnets to OCI services off the public internet (verify NoSQL Database service endpoint support for Service Gateway in your region).
- Vault: Store credentials/secrets where needed (though OCI-native auth often reduces secret usage).
- Monitoring + Alarms: Alert on throttling, high latency, or near-capacity usage.
- Audit: Track administrative changes and access patterns at the API level.
Dependency services
- OCI IAM (authentication + authorization)
- OCI compartments (resource scoping)
- OCI networking (if using private access patterns)
Security/authentication model (typical)
- Administrative operations: controlled by IAM policies (
nosql-familypermissions). - Application access: typically via OCI SDK using a principal (instance principal, resource principal, or user principal).
- Fine-grained data access patterns may exist, but you should verify the current support model in official docs.
Networking model
- Access is typically via OCI service endpoints in-region.
- To avoid public internet exposure from private subnets, many OCI architectures use a Service Gateway to reach OCI services through the Oracle Services Network (validate NoSQL Database support in your region).
Monitoring/logging/governance considerations
- Use Monitoring metrics + alarms for:
- Throttles / rate limiting
- Read/write unit consumption vs limits
- Error rates and latency (metrics depend on service)
- Use Audit to track:
- Table creation/deletion
- Policy-impacting actions
- Administrative updates
Simple architecture diagram (Mermaid)
flowchart LR
A[App / Script] -->|SDK / REST| N[Oracle Cloud NoSQL Database\n(Region)]
A --> I[OCI IAM]
N --> M[OCI Monitoring]
N --> AU[OCI Audit]
Production-style architecture diagram (Mermaid)
flowchart TB
subgraph VCN[OCI VCN]
subgraph PrivateSubnets[Private Subnets]
OKE[OKE / Microservices]
FN[OCI Functions\n(optional)]
end
SG[Service Gateway]
end
APIGW[OCI API Gateway] --> OKE
APIGW --> FN
OKE -->|IAM principal| IAM[OCI IAM]
FN -->|Resource principal| IAM
OKE -->|Private access via SG (if supported)| SG --> NOSQL[NoSQL Database\n(Regional Service)]
FN --> NOSQL
NOSQL --> MON[OCI Monitoring\nMetrics/Alarms]
NOSQL --> AUD[OCI Audit\nAdmin events]
OKE --> LOG[App Logs / Tracing\n(OCI Logging or 3rd party)]
FN --> LOG
VAULT[OCI Vault\n(Secrets/Keys)] -. optional .- OKE
8. Prerequisites
OCI account/tenancy requirements
- An active Oracle Cloud (OCI) tenancy
- Access to an OCI region where NoSQL Database is available (check regional availability in official docs)
Permissions / IAM roles
You need permissions to: – Create/manage tables in a compartment – Use the service from your application identity
A common starting policy for a lab (tighten for production):
Allow group <your-group-name> to manage nosql-family in compartment <your-compartment-name>
If you are using Cloud Shell, your user still needs permissions in IAM to manage NoSQL Database.
Production tip: Separate “table administrators” from “application runtime identities” and grant least privilege.
Billing requirements
- A billable OCI account or eligible Free Tier (if NoSQL Database is included in your tenancy’s Free Tier offering in your region—verify in official Free Tier docs).
Tools needed (choose one path)
- OCI Console (browser)
- OCI Cloud Shell (recommended for labs)
- OCI CLI (if working locally)
- One SDK (Python used in this tutorial)
Region availability
- Not every OCI service is available in every region. Verify service availability:
- OCI documentation and region/service availability pages (official)
Quotas/limits
- Check OCI Service Limits for NoSQL Database:
- Max tables per tenancy/compartment
- Max read/write units per table
- Max storage per table
- Any request size limits
- In Console: Governance & Administration → Limits, Quotas and Usage
Prerequisite services (optional but common)
- VCN + Service Gateway (for private subnet access patterns)
- OCI Monitoring (enabled by default in OCI)
- OCI Audit (enabled by default in OCI)
9. Pricing / Cost
Do not rely on blog posts for pricing. Always confirm on Oracle’s official pricing pages because SKUs and units can change by region and over time.
Current pricing model (how you are billed)
Oracle Cloud NoSQL Database pricing is typically based on provisioned capacity and storage, commonly including: – Read throughput units (or similar read capacity dimension) – Write throughput units (or similar write capacity dimension) – Storage (GB-month)
Some managed NoSQL services also offer on-demand request-based billing modes; if you see this option in your OCI Console for NoSQL Database, validate how it is priced in the official pricing documentation for your region.
Pricing dimensions to expect
- Provisioned read capacity (units/hour or units/month)
- Provisioned write capacity (units/hour or units/month)
- Storage used by table data and indexes (GB-month)
- Backups/snapshots (if offered/used; verify)
- Data transfer (usually charged when crossing regions or leaving OCI; see below)
Free tier (if applicable)
OCI has an Always Free/Free Tier program, but service inclusion varies. – Verify NoSQL Database Free Tier eligibility here: – OCI Free Tier: https://www.oracle.com/cloud/free/
Cost drivers (what increases your bill)
- Higher provisioned read/write capacity
- Large storage footprints, especially with indexes
- Inefficient access patterns that increase read units (scans, poorly selective queries)
- Multi-environment duplication (dev/test/prod tables)
- Cross-region traffic (if your app and NoSQL table are in different regions)
Hidden or indirect costs
- Networking costs:
- Data egress to the internet (varies)
- Inter-region data transfer (often billable)
- Compute costs:
- OKE nodes / Compute instances / Functions invocations that use the database
- Observability costs:
- Logging ingestion and retention if you push detailed logs
- Backups/export costs (if you implement exports to Object Storage)
Network/data transfer implications
- Keep application compute and NoSQL Database in the same region to minimize latency and avoid inter-region data transfer charges.
- Use VCN private access patterns (Service Gateway) to reduce public internet exposure; pricing impact is mostly about data transfer rather than routing method.
How to optimize cost
- Right-size read/write units; monitor throttles and utilization.
- Use TTL for ephemeral datasets (if supported).
- Minimize secondary indexes; index only what you query.
- Avoid table scans; design keys and access patterns carefully.
- Separate dev/test and apply automation to delete unused tables.
- Consider storing large blobs in Object Storage and only metadata/pointers in NoSQL Database.
Example low-cost starter estimate (no fabricated numbers)
A starter lab environment typically uses: – One small table – Minimal read/write capacity – 1–5 GB storage (or lower) – Light query volume
To estimate accurately: – Use the official pricing page and OCI cost tools: – Oracle Cloud pricing list: https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html (verify current URL in case Oracle updates it)
Example production cost considerations (what to plan for)
For production, plan for: – Peak read/write units (not just average) – Index storage and write amplification – Multiple tables per microservice – Separate compartments/environments – Monitoring alarms and SRE response processes
10. Step-by-Step Hands-On Tutorial
This lab creates a NoSQL Database table in Oracle Cloud, writes a few records, queries them, and then cleans up. The workflow is designed to be safe and low-cost by using small table limits.
Command syntax and API parameters can evolve. If any CLI/SDK commands differ in your environment, follow the official docs for the exact flags and names.
Objective
- Create a NoSQL Database table in Oracle Cloud
- Insert and read records
- Run a simple query
- Validate results
- Clean up resources to stop ongoing charges
Lab Overview
You will: 1. Create an IAM policy (if needed) and choose a compartment 2. Create a NoSQL table with small limits 3. Use Cloud Shell with Python SDK (or CLI if preferred) to insert/query data 4. Validate data and observe common failure modes 5. Delete the table
Step 1: Prepare your compartment and permissions
1) Choose or create a compartment for the lab, for example:
– labs-data-management
2) Ensure your user belongs to a group with permissions. For a lab, an admin can create this policy in the target compartment:
Allow group <your-group-name> to manage nosql-family in compartment <your-compartment-name>
Expected outcome – You have permissions to create and delete NoSQL tables.
Verification – In OCI Console, search for NoSQL Database. You should be able to open the service without authorization errors.
Step 2: Create a NoSQL Database table (Console)
1) In OCI Console, open: – NoSQL Database
2) Confirm the Region (top right) is the region you want.
3) Click Create Table (label may vary slightly by console updates).
4) Select:
– Compartment: your lab compartment
– Table name: users_lab
5) Provide a DDL statement. Oracle NoSQL table DDL commonly looks like this (verify syntax in current docs if your console validates differently):
CREATE TABLE IF NOT EXISTS users_lab (
user_id INTEGER,
email STRING,
full_name STRING,
created_at TIMESTAMP,
PRIMARY KEY (SHARD(user_id))
)
6) Set small table limits (names vary by UI). Use minimal values allowed, for example: – Read units: minimal – Write units: minimal – Storage: minimal (for example 1 GB if that’s the minimum)
7) Create the table.
Expected outcome – Table status becomes Active (or similar).
Verification – In the table details page, confirm: – Lifecycle state is Active – Limits/capacity are visible – You can see DDL and primary key definition
Step 3: Use Cloud Shell to connect and write/query data (Python SDK path)
This step uses Cloud Shell so you don’t have to manage local OCI CLI auth.
1) Open Cloud Shell from the OCI Console.
2) Confirm your OCI CLI is authenticated:
oci os ns get
Expected outcome – A JSON response with your namespace (proves your CLI session works).
3) Install the Oracle NoSQL Database SDK for Python.
Oracle’s Python SDK for NoSQL Database is typically distributed as borneo. Install it:
python3 -m pip install --user borneo
Expected outcome – Package installs successfully.
4) Create a Python script nosql_lab.py.
You must set:
– Your region id (example: us-ashburn-1) to match your current region
– The compartment OCID
– The table name
Get your compartment OCID from the compartment details page.
Create the script:
#!/usr/bin/env python3
import os
import time
from borneo import (
NoSQLHandle, NoSQLHandleConfig,
PutRequest, GetRequest, QueryRequest
)
from borneo.iam import SignatureProvider
from borneo.exception import NoSQLException
# ---- Configure these values ----
REGION_ID = os.environ.get("OCI_REGION_ID", "") # optional env override
COMPARTMENT_OCID = os.environ.get("OCI_COMPARTMENT_OCID", "")
TABLE_NAME = "users_lab"
if not COMPARTMENT_OCID:
raise SystemExit("Set OCI_COMPARTMENT_OCID env var to your compartment OCID.")
# Cloud Shell typically has ~/.oci/config configured.
# If your profile is not DEFAULT, set OCI_PROFILE.
profile = os.environ.get("OCI_PROFILE", "DEFAULT")
# Region: try Cloud Shell env, fallback to explicit value.
# If REGION_ID is empty, set it explicitly (example: 'us-ashburn-1').
if not REGION_ID:
raise SystemExit("Set OCI_REGION_ID (example: us-ashburn-1).")
provider = SignatureProvider(config_file="~/.oci/config", profile_name=profile)
config = NoSQLHandleConfig(region=REGION_ID, provider=provider)
# Optional tuning:
# config.set_default_compartment(COMPARTMENT_OCID)
handle = NoSQLHandle(config)
def put_user(user_id, email, full_name):
row = {
"user_id": user_id,
"email": email,
"full_name": full_name,
"created_at": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())
}
req = PutRequest().set_table_name(TABLE_NAME).set_value(row)
# Many SDKs support setting compartment at request time; if needed:
req.set_compartment(COMPARTMENT_OCID)
res = handle.put(req)
return res
def get_user(user_id):
key = {"user_id": user_id}
req = GetRequest().set_table_name(TABLE_NAME).set_key(key)
req.set_compartment(COMPARTMENT_OCID)
res = handle.get(req)
return res.get_value()
def query_users():
# SQL-like query language; verify supported syntax for your environment.
stmt = f"SELECT user_id, email, full_name, created_at FROM {TABLE_NAME} ORDER BY user_id"
req = QueryRequest().set_statement(stmt)
req.set_compartment(COMPARTMENT_OCID)
results = []
while True:
res = handle.query(req)
results.extend(res.get_results())
if req.is_done():
break
return results
try:
print("Inserting users...")
put_user(1, "alice@example.com", "Alice Adams")
put_user(2, "bob@example.com", "Bob Brown")
put_user(3, "cara@example.com", "Cara Clark")
print("Reading user_id=2 ...")
user = get_user(2)
print(user)
print("Query all users ...")
rows = query_users()
for r in rows:
print(r)
finally:
handle.close()
5) Export environment variables and run.
Set your region id (use the OCI region you are in) and compartment OCID:
export OCI_REGION_ID="us-ashburn-1"
export OCI_COMPARTMENT_OCID="ocid1.compartment.oc1..exampleuniqueID"
python3 nosql_lab.py
Expected outcome – The script inserts 3 rows, reads user 2, and prints query results.
Verification – In the OCI Console NoSQL table view, if there is a data/query view available in your region/console version, you should see the inserted data. – If not, rely on the script output as validation.
Step 4: (Optional) Create an index for email lookups (only if supported)
If your workload needs email -> user lookup, you typically add a secondary index.
Index DDL varies by NoSQL implementation. If the console provides an “Indexes” tab, use the console to create an index on email.
Expected outcome – Index is created and becomes Active.
Verification – Query by email if supported by your query language and index model.
If index creation is not available in your region/service version, do not force it—design your primary key to meet your query needs.
Validation
Use a checklist: – Table exists and is Active. – Script can authenticate and perform Put/Get/Query. – Results show inserted records.
Recommended additional validation: – Run the script twice to observe idempotency behavior (a Put may overwrite existing key). – Temporarily reduce capacity (if supported) and observe throttling behavior under load (in a controlled manner).
Troubleshooting
Common issues and realistic fixes:
1) NotAuthorizedOrNotFound / 403
– Cause: Missing IAM policy for nosql-family in the compartment.
– Fix: Ensure group policy includes manage nosql-family (lab) or correct least-privilege permissions (prod).
2) Region mismatch
– Cause: Script points to a different region than where the table exists.
– Fix: Set OCI_REGION_ID to the region where you created the table.
3) Table not found – Cause: Wrong compartment OCID or table name. – Fix: Confirm compartment OCID; confirm table exists in that compartment/region.
4) Python SDK errors (borneo import or provider)
– Cause: Package not installed in the correct Python environment.
– Fix:
– Use python3 -m pip install --user borneo
– Ensure you run with python3
5) Throttling / TooManyRequests – Cause: Table capacity too low for your request burst. – Fix: – Increase read/write units for the table (small increments) – Implement exponential backoff retries in application code
Cleanup
To avoid ongoing charges, delete the table.
Console cleanup
1) Open NoSQL Database
2) Select the users_lab table
3) Choose Delete
4) Confirm deletion
Expected outcome – Table lifecycle state changes to Deleting and then disappears.
Also remove (or narrow) any overly broad IAM policies created solely for the lab.
11. Best Practices
Architecture best practices
- Model data by access pattern: design keys so your most frequent queries are key-based.
- Pick shard/partition keys that distribute load evenly:
- Avoid monotonically increasing keys alone (can cause hot partitions).
- Prefer high-cardinality keys (userId, deviceId, tenantId).
- Use denormalization intentionally: duplicate small bits of data to avoid joins.
- Store large blobs externally (Object Storage), keep pointers in NoSQL Database.
IAM/security best practices
- Use compartments per environment (dev/test/prod).
- Prefer workload identities (instance principal/resource principal) over long-lived user keys for apps.
- Apply least privilege:
- Separate “manage tables” from “read/write data” identities if supported by the service’s permission model (verify exact permissions in docs).
- Tag tables for ownership and cost allocation.
Cost best practices
- Start small, measure, then scale:
- Set minimal read/write units for dev.
- Use production load tests to right-size capacity.
- Keep indexes minimal and purposeful.
- Use TTL for ephemeral datasets (if supported).
- Delete unused tables and test environments automatically.
Performance best practices
- Avoid scans and unbounded queries.
- Keep item/record size small and consistent when possible.
- Batch operations if the SDK supports it (verify).
- Implement retries with exponential backoff for throttling and transient failures.
Reliability best practices
- Design for retries and idempotency at the application layer.
- Use circuit breakers/timeouts in the client.
- Consider multi-region DR patterns at the application level if your business requires it; confirm NoSQL Database replication capabilities in official docs.
Operations best practices
- Create alarms on:
- throttling events
- near-capacity utilization
- elevated error rates
- Track deployment changes with tags and Terraform (infrastructure as code).
- Standardize naming:
<env>-<domain>-<service>-<table>- Example:
prod-commerce-cart-users
Governance/tagging/naming best practices
- Apply defined tags:
CostCenter,Owner,Environment,DataClassification- Document table schemas, key design, and expected access patterns in a repo.
12. Security Considerations
Identity and access model
- Controlled by OCI IAM:
- Policies grant permissions to groups or dynamic groups in compartments.
- Application authentication should use:
- Instance Principals (Compute)
- Resource Principals (Functions)
- Or secure user principals for development only
Encryption
- OCI managed services typically provide encryption at rest and TLS in transit.
- Verify encryption specifics for NoSQL Database in the official security documentation:
- Key management model (Oracle-managed keys vs customer-managed keys, if available)
Network exposure
- Prefer private access patterns:
- Use private subnets for workloads
- Use Service Gateway to reach OCI services without public internet traversal (verify NoSQL Database support)
Secrets handling
- Avoid embedding OCI credentials in code.
- If you must use API keys for development:
- Store them in OCI Vault or in a secure secrets manager
- Rotate keys regularly
Audit/logging
- Enable and monitor OCI Audit for administrative actions.
- Log application access patterns at the application layer (request IDs, latency, errors).
- Avoid logging sensitive data fields.
Compliance considerations
- Classify data:
- PII should be minimized, tokenized, or encrypted at the application layer if required by policy.
- Use compartments and policies aligned to regulatory boundaries.
Common security mistakes
- Granting broad
manage nosql-familyto too many users/roles - Using long-lived user API keys in production workloads
- Storing secrets in code repos or container images
- Exposing workloads publicly when private access is possible
Secure deployment recommendations
- Separate admin and runtime identities.
- Use least privilege and compartment boundaries.
- Use Vault for secrets and consider customer-managed keys if supported and required (verify availability).
- Monitor audit logs and set alerts for unusual administrative actions.
13. Limitations and Gotchas
Specific limits can change. Check OCI Service Limits and the NoSQL Database docs for current numbers.
Common limitations and operational gotchas to plan for:
- Key design is critical: hot partitions/shards will throttle even if total capacity looks sufficient.
- Secondary indexes cost writes: every write may update index structures, increasing write units and storage.
- Query flexibility is not relational: no joins; complex analytics queries are not the goal.
- Throttling behavior: if you exceed provisioned capacity, expect rate limiting; clients must retry with backoff.
- Large items/records: request size limits may apply; keep records reasonably sized and store blobs elsewhere.
- Environment drift: without IaC (Terraform), it’s easy for dev/prod table limits and indexes to drift.
- Region constraints: you must create and access tables in the correct region; cross-region latency can be significant.
- Cost surprises:
- Overprovisioned read/write units
- Unused indexes
- Long-retained data without TTL
- Migration challenges:
- DynamoDB/Cosmos/Mongo data models don’t map 1:1; plan key/index translation and consistency semantics carefully.
- Feature availability differences:
- Some capabilities may differ between Oracle NoSQL Database on-prem and OCI NoSQL Database; always validate against the OCI docs for your service.
14. Comparison with Alternatives
Nearest services in Oracle Cloud
- Oracle Autonomous Database (including JSON support): best for relational + SQL + analytics and mixed workloads.
- Oracle MySQL HeatWave: relational MySQL with performance features, often for transactional + analytics patterns.
- OCI Object Storage: durable blob storage, not a low-latency key-value database.
- OCI Streaming: event streaming, not a database; commonly paired with NoSQL for state.
Nearest services in other clouds
- AWS DynamoDB
- Azure Cosmos DB
- Google Cloud Firestore / Bigtable (depending on model)
Open-source / self-managed alternatives
- Apache Cassandra (self-managed)
- MongoDB (self-managed or MongoDB Atlas)
- Redis (for caching; not a durable system of record unless configured carefully)
Comparison table
| Option | Best For | Strengths | Weaknesses | When to Choose |
|---|---|---|---|---|
| Oracle Cloud NoSQL Database | Low-latency key-value/document workloads on OCI | OCI IAM/compartments integration, managed ops, predictable capacity planning | Requires careful key modeling; not relational; verify advanced multi-region patterns | You run workloads on OCI and need managed NoSQL for OLTP patterns |
| Oracle Autonomous Database (JSON/ATP) | SQL, joins, mixed workloads, analytics | Rich SQL, strong transactional semantics, mature tooling | More complex/costly for simple KV access; relational modeling overhead | You need SQL analytics + transactions and can model relationally |
| MySQL HeatWave (OCI) | MySQL OLTP + acceleration | MySQL ecosystem, familiar tooling | Relational constraints; scaling patterns differ | You need MySQL compatibility and relational queries |
| AWS DynamoDB | Managed KV at massive scale | Mature ecosystem, global tables (service-specific) | AWS lock-in; different IAM/tooling | You are primarily on AWS and need DynamoDB features |
| Azure Cosmos DB | Multi-model globally distributed NoSQL | Global distribution options (service-specific), multiple APIs | Cost/complexity; modeling varies by API | You are on Azure and need Cosmos global distribution |
| MongoDB (Atlas/self-managed) | Document database with rich query | Flexible documents, rich indexing and query | Operational overhead (self-managed) or added managed cost | You want MongoDB semantics and ecosystem |
| Cassandra (self-managed) | High write throughput, wide-column | Scale-out, tunable consistency | Significant ops complexity | You need Cassandra model and can operate clusters |
15. Real-World Example
Enterprise example: Telecom device state platform
- Problem: A telecom operator needs to store the latest configuration and connectivity status for tens of millions of devices. Reads happen on every API call; writes happen when devices report in.
- Proposed architecture:
- OKE microservices in private subnets
- Service Gateway to reach NoSQL Database privately (verify service support)
- NoSQL Database table keyed by
deviceId(shard key) to distribute load - Secondary index (if supported) for
customerIdorstatusused by support tools - Streaming pipeline writes events to Object Storage; NoSQL stores only latest state and pointers
- Monitoring alarms on throttling and latency; Audit for admin actions
- Why NoSQL Database was chosen:
- Predictable low-latency key lookups at high scale
- Managed operations with OCI governance
- Clear separation of state (NoSQL) vs raw events (Object Storage)
- Expected outcomes:
- Sub-10ms (target) state read latency within region (actual depends on design and provisioning)
- Simplified ops compared to self-managed clusters
- Controlled cost via provisioned throughput and TTL for ephemeral records
Startup/small-team example: SaaS feature flags service
- Problem: A startup needs a simple, reliable store for feature flags and tenant config that is read on every request across microservices.
- Proposed architecture:
- OCI API Gateway → Functions for admin APIs
- OKE/Compute microservices read flags directly via SDK
- NoSQL Database table keyed by
(tenantId, flagName)(tenantId as shard key) - TTL for temporary flags (if supported)
- CI/CD uses Terraform to deploy table and policies
- Why NoSQL Database was chosen:
- Minimal ops burden for a small team
- Tight IAM/compartment governance in OCI
- Low-latency reads for every API call
- Expected outcomes:
- Faster feature rollout and safer experimentation
- Predictable cost via small provisioned capacity and right-sized scaling
16. FAQ
1) Is “NoSQL Database” the same as “Oracle NoSQL Database Cloud Service”?
In OCI, the console service is often labeled NoSQL Database, while Oracle documentation may refer to Oracle NoSQL Database Cloud Service. They refer to the managed NoSQL service on Oracle Cloud. Verify naming in your OCI Console and the latest docs.
2) Is NoSQL Database a document database or key-value store?
It is commonly used as a key-value and table-based NoSQL datastore with support for semi-structured data and a SQL-like query language. The exact data model and API features depend on the SDK and service capabilities—verify in official docs.
3) Do I need to manage servers or clusters?
No. It’s a managed OCI service; you manage tables, capacity/limits, and access control.
4) How do I control access?
With OCI IAM policies and compartments. Use least privilege and separate admin vs runtime identities.
5) Can I access NoSQL Database privately from a VCN?
Often OCI services can be reached from private subnets via a Service Gateway. Verify NoSQL Database support for Service Gateway in your region.
6) What is the most important design decision?
Your primary key/shard key design. It affects distribution, scalability, and hot-spot risk.
7) Does it support secondary indexes?
Many NoSQL table services do, but capabilities can vary. Check the NoSQL Database documentation for current index support and limits.
8) Does it support transactions?
Some NoSQL systems offer limited transactional/atomic operations (often within a partition/shard key). Confirm current transactional semantics in the official docs.
9) How do I avoid throttling?
Provision sufficient capacity, design keys to distribute load evenly, and implement retries with exponential backoff.
10) Is it suitable for analytics or reporting?
Not typically. Use a data warehouse or Autonomous Database for analytics; use NoSQL Database for operational access patterns.
11) How do I estimate cost?
Use Oracle’s official pricing pages and OCI cost estimator. Cost is usually driven by read/write capacity and storage.
12) Can I store large JSON payloads?
You can store semi-structured records, but request size limits may apply and large payloads increase cost and latency. Store large blobs in Object Storage and keep pointers in NoSQL Database.
13) How do I back up data?
Backup/restore options vary by service. If native backups exist, use them; otherwise implement export pipelines (for example to Object Storage). Verify the supported approach in official docs.
14) How do I migrate from DynamoDB/CosmosDB/MongoDB?
Plan a migration that maps keys, indexes, and consistency semantics carefully. Expect application changes; NoSQL models are not 1:1 across vendors.
15) What should I monitor in production?
Throttling, latency, error rates, and capacity utilization (read/write units and storage). Use OCI Monitoring alarms and application-level tracing.
16) Can I use Terraform for NoSQL Database?
OCI supports Terraform for many services. Verify current Terraform resource support for NoSQL Database in the OCI Terraform provider documentation.
17) Is NoSQL Database “serverless”?
It’s managed and you don’t run servers, but you usually choose capacity/limits. Whether it offers a fully on-demand serverless billing mode should be verified in the current pricing/docs.
17. Top Online Resources to Learn NoSQL Database
| Resource Type | Name | Why It Is Useful |
|---|---|---|
| Official documentation | OCI NoSQL Database docs: https://docs.oracle.com/en-us/iaas/Content/NoSQL/home.htm | Primary source for features, limits, IAM, networking, and SDK usage |
| Official product page | Oracle NoSQL Database Cloud Service: https://www.oracle.com/cloud/cloud-native/nosql-database/ | High-level capabilities and entry points to docs |
| Official pricing | Oracle Cloud Price List: https://www.oracle.com/cloud/price-list/ | Official SKU-based pricing reference (region/SKU may vary) |
| Pricing calculator/estimator | OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html | Helps build cost estimates without guessing prices |
| IAM documentation | OCI IAM policies: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm | Learn how to write least-privilege policies for nosql-family |
| Networking documentation | Service Gateway overview: https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/servicegateway.htm | Private access from VCNs to OCI services |
| Monitoring documentation | OCI Monitoring: https://docs.oracle.com/en-us/iaas/Content/Monitoring/home.htm | Metrics, alarms, and operational monitoring patterns |
| Audit documentation | OCI Audit: https://docs.oracle.com/en-us/iaas/Content/Audit/home.htm | Governance trail for administrative operations |
| Official SDK (Python) | Oracle NoSQL Python SDK (borneo): https://github.com/oracle/nosql-python-sdk | Practical code examples and SDK reference |
| Official SDK (Java) | Oracle NoSQL Java SDK: https://github.com/oracle/nosql-java-sdk | Java client patterns used in enterprise services |
| Official SDK (Node.js) | Oracle NoSQL Node.js SDK: https://github.com/oracle/nosql-node-sdk | Node.js client patterns for APIs and microservices |
| OCI CLI | OCI CLI docs: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm | Automate table creation and ops workflows |
| Architecture guidance | OCI Architecture Center: https://docs.oracle.com/en/solutions/ | Reference architectures and best practices (filter for data management patterns) |
| Community learning | Oracle Cloud Infrastructure workshops/tutorials (catalog): https://oracle-devrel.github.io/ | Hands-on labs; verify NoSQL coverage and currency |
18. Training and Certification Providers
| Institute | Suitable Audience | Likely Learning Focus | Mode | Website URL |
|---|---|---|---|---|
| DevOpsSchool.com | DevOps engineers, SREs, cloud engineers | OCI operations, DevOps pipelines, cloud fundamentals, service integrations | Check website | https://www.devopsschool.com/ |
| ScmGalaxy.com | Beginners to intermediate engineers | SCM/DevOps foundations, cloud tooling, operational practices | Check website | https://www.scmgalaxy.com/ |
| CLoudOpsNow.in | Cloud ops and platform teams | Cloud operations, monitoring, reliability practices | Check website | https://www.cloudopsnow.in/ |
| SreSchool.com | SREs and reliability-focused teams | SRE practices, observability, incident response, reliability engineering | Check website | https://www.sreschool.com/ |
| AiOpsSchool.com | Ops teams adopting automation | AIOps concepts, monitoring automation, operational analytics | Check website | https://www.aiopsschool.com/ |
19. Top Trainers
| Platform/Site | Likely Specialization | Suitable Audience | Website URL |
|---|---|---|---|
| RajeshKumar.xyz | Cloud/DevOps training and guidance (verify current offerings) | Engineers seeking practical coaching | https://rajeshkumar.xyz/ |
| devopstrainer.in | DevOps and cloud training platform (verify course catalog) | Beginners to intermediate DevOps learners | https://devopstrainer.in/ |
| devopsfreelancer.com | Freelance DevOps help/training (verify services) | Teams needing short-term enablement | https://www.devopsfreelancer.com/ |
| devopssupport.in | DevOps support and training (verify scope) | Ops teams needing hands-on support | https://www.devopssupport.in/ |
20. Top Consulting Companies
| Company | Likely Service Area | Where They May Help | Consulting Use Case Examples | Website URL |
|---|---|---|---|---|
| cotocus.com | Cloud/DevOps consulting (verify practice areas) | Architecture, CI/CD, operations | OCI landing zones, migration planning, observability setup | https://cotocus.com/ |
| DevOpsSchool.com | Training + consulting services (verify offerings) | Platform engineering, DevOps transformation | Designing IaC, building deployment pipelines, SRE enablement | https://www.devopsschool.com/ |
| DEVOPSCONSULTING.IN | DevOps consulting (verify focus) | DevOps automation, cloud operations | Implementing CI/CD, monitoring, security hardening | https://www.devopsconsulting.in/ |
21. Career and Learning Roadmap
What to learn before NoSQL Database (Oracle Cloud)
- OCI fundamentals: regions, compartments, VCNs, IAM
- Basic database concepts: keys, indexing, consistency, CAP tradeoffs
- API development fundamentals (REST/gRPC) and authentication concepts
- Observability basics: metrics, logs, tracing
What to learn after
- Advanced data modeling for NoSQL: partitioning, hot key mitigation, denormalization
- Infrastructure as Code (Terraform for OCI)
- Secure workload identity on OCI (instance principals/resource principals)
- Event-driven patterns with OCI Streaming + Functions/OKE
- Data lake patterns with Object Storage + analytics services
Job roles that use it
- Cloud engineer / platform engineer (OCI)
- Backend engineer building microservices
- DevOps/SRE supporting managed data services
- Solutions architect designing operational data layers
Certification path (if available)
Oracle’s certification offerings change over time. For the most accurate path: – Check Oracle University and OCI certifications pages (official): – https://education.oracle.com/ – https://education.oracle.com/oracle-cloud-infrastructure-certification
Project ideas for practice
- Build a session store microservice with TTL and alarms for throttling
- Create a tenant registry for a multi-tenant SaaS (keys: tenantId, config)
- Implement an idempotency key service for payment APIs
- Create a telemetry “latest state” service storing device snapshots and pointers to Object Storage
22. Glossary
- OCI (Oracle Cloud Infrastructure): Oracle Cloud’s core platform for compute, networking, storage, and managed services.
- Compartment: OCI resource container used for access control and organization.
- IAM Policy: A rule granting permissions to groups/dynamic groups in OCI.
- NoSQL Table: Container for records in NoSQL Database.
- Primary Key: Uniquely identifies a record. Often includes a shard/partition key element.
- Shard Key / Partition Key: Key component used to distribute data across partitions for scalability.
- Secondary Index: Index on non-primary-key fields to support additional queries.
- TTL (Time to Live): Data expiration mechanism to automatically remove old records.
- Provisioned Capacity: Pre-allocated throughput (read/write units) used for predictable performance and billing.
- Throttling: Rate limiting when workload exceeds provisioned limits.
- Service Gateway: OCI networking component that enables private access from a VCN to OCI services (Oracle Services Network).
- Data plane: Runtime read/write/query traffic.
- Control plane: Administrative operations such as table creation, updates, and deletion.
23. Summary
Oracle Cloud NoSQL Database (in the Data Management category) is OCI’s managed NoSQL service for low-latency, high-throughput operational workloads where key-based access patterns and predictable performance matter.
It fits best when you can design effective primary/shard keys, keep queries bounded, and provision capacity based on real throughput needs. Cost is typically driven by read/write capacity and storage, with additional indirect costs from networking, compute runtimes, and logging. Security is anchored in OCI IAM + compartments, with Audit for governance and Monitoring for operational visibility.
Use NoSQL Database for sessions, profiles, device state, carts, and configuration; choose relational or analytics services when you need joins, complex SQL, or reporting. Next step: read the official NoSQL Database docs and implement a small proof-of-concept with proper key modeling, monitoring alarms, and least-privilege IAM policies.
