ORACLE NOSQL → STACKIT MONGODB FLEX · ARCHITECTURE
Oracle NoSQL on STACKIT: redesigning the data model
There is no drop-in target for an Oracle NoSQL table. StackToIT classes each table as REDESIGN with STACKIT MongoDB Flex as the candidate, with LOW confidence, because the data model, the query API and the capacity model are Oracle’s own. This page shows the assessed estate, the options for the target, and a concept-by-concept table to remodel keys, JSON, expiry, indexes and consistency.
Two NoSQL tables, assessed
A sessions table with an expiry and a carts table, written for this page and assessed by StackToIT on 4 November 2026. Left: the input, lines 16 to 38 of main.tf. Right: the result, an excerpt of assessment.json with the values as the run wrote them. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.
resource "oci_nosql_table" "sessions" {
compartment_id = var.compartment_id
name = "sessions"
ddl_statement = "CREATE TABLE IF NOT EXISTS sessions (session_id STRING, user_id STRING, payload JSON, expires_at TIMESTAMP(3), PRIMARY KEY (SHARD(user_id), session_id)) USING TTL 1 DAYS"
table_limits {
max_read_units = 50
max_write_units = 50
max_storage_in_gbs = 10
capacity_mode = "PROVISIONED"
}
}
resource "oci_nosql_table" "carts" {
compartment_id = var.compartment_id
name = "carts"
ddl_statement = "CREATE TABLE IF NOT EXISTS carts (cart_id STRING, customer_id STRING, items JSON, PRIMARY KEY (cart_id))"
table_limits {
max_storage_in_gbs = 25
capacity_mode = "ON_DEMAND"
}
}[
{
"id": "oci_nosql_table.sessions",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"target": {
"service": "STACKIT MongoDB Flex"
},
"reason": "OCI NoSQL has its own data model and API. The tables and clients are redesigned for MongoDB Flex."
}
},
{
"id": "oci_nosql_table.carts",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"target": {
"service": "STACKIT MongoDB Flex"
},
"reason": "OCI NoSQL has its own data model and API. The tables and clients are redesigned for MongoDB Flex."
}
}
]REDESIGN, on purpose
The run states that OCI NoSQL has its own data model and API, and that the tables and clients are redesigned for MongoDB Flex. The class is not a defect: it tells you the work is design, not copying.
LOW confidence
Both tables are LOW. The run records the feasibility as conditional, with a feature gap as the blocker category, so the answer depends on what your application uses.
Clients change too
A DDL statement, a SQL-like query and an SDK call are all Oracle specific. The redesign covers the application code that talks to the table.
The index the run does not know
The secondary index on the carts table is declared as its own resource. The run keeps it, and says plainly that it did not assess it. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.
resource "oci_nosql_index" "carts_by_customer" {
table_name_or_id = oci_nosql_table.carts.id
compartment_id = var.compartment_id
name = "carts_by_customer"
keys {
column_name = "customer_id"
}
}[
{
"id": "oci_nosql_index.carts_by_customer",
"result": {
"class": "MANUAL_REVIEW",
"confidence": "LOW",
"reason": "oci_nosql_index is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
}
}
]MANUAL_REVIEW for the index
The index type is not in the catalogue of the run, so nothing of it is assessed or drafted. The table it belongs to carries a warning that the index is linked but not assessed.
Where it goes in the plan
The index sits in wave 2 and the tables in wave 1. In practice you design the indexes together with the collections, from the queries the application runs.
Concept by concept: from OCI NoSQL to MongoDB Flex
The left column is documented by Oracle, the middle column by STACKIT where it says so, and the last column is the question you answer in the design.
| OCI NoSQL concept | On MongoDB Flex | What you decide |
|---|---|---|
| Table with a primary key and shard key | A collection of documents; STACKIT describes the service as fully compatible with native MongoDB | The document key, and which fields lead the indexes. Oracle shards by part of the primary key; the STACKIT page describes no per-table shard key, so design from the access patterns. |
| JSON column | A document, stored as BSON, with a dynamic schema | Whether to keep the payload as one embedded object or to lift fields into the document. |
| Typed columns | Document fields | How much validation the application does, since a document store does not enforce your DDL. |
| TTL on rows (USING TTL 1 DAYS) | An expiry mechanism of the database, for example a TTL index, designed per collection | The expiry field, the clean-up delay you can accept, and a test that expired sessions really disappear. |
| Secondary index, including on JSON paths | Indexes: single field, compound, geospatial and text are listed by STACKIT | One index per query path; no automatic carry-over from the OCI index. |
| Provisioned read and write units, or on-demand | An instance you size when you create it; the STACKIT page read for this guide describes no per-table throughput setting | Peak reads and writes, translated into the size of the instance; there is no per-table unit setting to copy. |
| Read consistency ABSOLUTE or EVENTUAL | Read and write behaviour is set in the driver and the deployment (general practice) | Which reads must see the latest write; in Oracle ABSOLUTE reads cost twice the read units, so use them only where required. |
| Table hierarchy with joins | Aggregations with $lookup, or embedding | Whether parent and child rows become one document. |
| Global active tables | Not described on the STACKIT page read for this guide | Whether you replicate across regions at all, and how; plan it as a separate design. |
Oracle states that ACID transactions are supported; the MongoDB Flex page lists authentication, role-based access control, encryption and auditing. The concrete guarantees you need are to be confirmed against the service before you rely on them.
Options for the target
The run proposes one. These are the choices an architect weighs; no benchmark is implied.
MongoDB Flex, the run’s candidate
Best when the data is genuinely document shaped and the application can move to a document API. STACKIT lists dynamic schemas, aggregations and several index types.
PostgreSQL Flex with JSONB
Best when you want one relational service for typed columns and a JSON column together, and accept rewriting queries to SQL. A design alternative outside the run.
Key Value Store (Valkey) for sessions
A sessions table with a one-day expiry is a cache in all but name. If nothing queries it by anything but its key, a key value store with expiring keys can fit better than a document collection. Another design alternative outside the run.
Split by workload
The two tables in the demo need not land in the same service. Decide per table from its access pattern, then merge only where it saves operating effort.
A design sequence that works
General practice, not a run result. Each step produces something a reviewer can check.
List the access patterns
For each table write down every read and write: by which key, how often, how fresh the data must be.
Choose the target per table
Use the options above and record why, so the decision is not repeated later.
Draw the documents or rows
One example record per collection, with its key and indexes, reviewed with the team that owns the application.
Rewrite the data access layer
Replace the Oracle SDK calls and the SQL-like queries; keep the change behind one interface so it can be tested.
Load and compare
Export from the source, transform, load, and compare counts and sample records. The run does not move data and states that the mechanism is for you to choose.
Questions application teams ask
Why is the class REDESIGN and not REPLATFORM?
Because Oracle NoSQL has its own data model and API. The tables and the clients are redesigned for MongoDB Flex; a copy of the data alone would leave an application that cannot read it.
Is MongoDB Flex the only target?
It is the candidate the run names. PostgreSQL Flex with JSONB or a key value store can fit specific tables better; these are design alternatives you evaluate, not run results.
What happens to the TTL setting?
The row expiry is a feature of the Oracle table. On the target you design an expiry per collection and test it. The run does not translate the DDL statement.
Do we lose the Oracle capacity model?
Provisioned or on-demand read and write units do not carry over. On the target you size the instance, so you translate your peak load once and review it after the first weeks of traffic.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.