NoSQL Generic Guide

Use the generic NoSQL format when you want to represent document-style or collection-based data that does not map cleanly to a SQL schema.

Expected JSON shape

The input format is intentionally simple:

• root object with a collections array
• each collection has a name
• each collection has a fields object
• each field maps to a type string

Supported field types

• string
• number
• boolean
• date
• array<string>
• array<number>
• array<boolean>
• array<date>

Example

{
  "collections": [
    {
      "name": "users",
      "fields": {
        "id": "string",
        "age": "number",
        "isActive": "boolean",
        "createdAt": "date",
        "tags": "array<string>"
      }
    },
    {
      "name": "orders",
      "fields": {
        "id": "string",
        "userId": "string",
        "total": "number",
        "lines": "array<string>"
      }
    }
  ]
}

When to use this format

• internal document stores
• schema-like JSON definitions used by platform teams
• high-level modeling when the underlying store is not relational

Recommended approach

• keep the schema concise and readable
• focus on fields that matter for shared understanding
• use stable collection names that match how your teams talk about the domain
• version the JSON file with the service it describes

Related docs

• SQL Import Guide
• DynamoDB Guide
• UIGraph CLI database sync