Skip to main content

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
  • 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