Metadata and Filters

Metadata is structured data attached to each knowledge source and memory. You send it at ingest, and at query time metadata_filters on POST /query keeps only the sources whose values match, such as department = legal or status = published, before ranking runs. In this guide:

Declare a field and filter on it: create the schema, ingest with metadata, and query with a filter.
The two layers: metadata and additional_metadata, and how a filter runs.
Filter operators: equals, contains, and contains_any, and how to store several values in one field.
Size limits: caps on stored metadata and on the filter you send.
Add schema fields later.
Update metadata without re-ingesting.
List sources with metadata filters.
Schema field reference, common mistakes, and related pages.

1. Declare a field and filter on it

Three requests: create the database with a metadata schema, ingest a source that carries values for those fields, then query with metadata_filters. The example declares department, priority, and a summary_label field that is also searchable as text.

Create the database with a metadata schema: Python, TypeScript, or cURL

Set up your SDK client before running the Python or TypeScript example.

import os
from hydra_db import HydraDB

client = HydraDB(token=os.environ["HYDRA_DB_API_KEY"])

client.databases.create(
    database="acme_corp",
    database_metadata_schema=[
        {"name": "department", "data_type": "VARCHAR"},
        {"name": "priority", "data_type": "INT64"},
        {
            "name": "summary_label",
            "data_type": "VARCHAR",
            "enable_dense_embedding": True,
            "enable_sparse_embedding": True,
        },
    ],
)

import { HydraDBClient } from "@hydradb/sdk";

const client = new HydraDBClient({
  token: process.env.HYDRA_DB_API_KEY,
});

await client.databases.create({
  database: "acme_corp",
  databaseMetadataSchema: [
    { name: "department", dataType: "VARCHAR" },
    { name: "priority", dataType: "INT64" },
    {
      name: "summary_label",
      dataType: "VARCHAR",
      enableDenseEmbedding: true,
      enableSparseEmbedding: true,
    },
  ],
});

curl -X POST 'https://api.hydradb.com/databases' \
  -H "Authorization: Bearer $HYDRA_DB_API_KEY" \
  -H "API-Version: 2" \
  -H "Content-Type: application/json" \
  -d '{
    "database": "acme_corp",
    "database_metadata_schema": [
      { "name": "department", "data_type": "VARCHAR" },
      { "name": "priority", "data_type": "INT64" },
      {
        "name": "summary_label",
        "data_type": "VARCHAR",
        "enable_dense_embedding": true,
        "enable_sparse_embedding": true
      }
    ]
  }'

Ingest a source with metadata: Python, TypeScript, or cURL

After creating the database, wait for GET /databases/status to report infra.ready_for_ingestion: true before ingesting.Send metadata and additional_metadata on each app_knowledge[] item, or on each document_metadata[] item when you upload files. For type=memory, the memories field is already a JSON string, and each memory item’s metadata and additional_metadata are plain objects inside it; do not stringify them a second time.

import json

client.context.ingest(
    type="knowledge",
    database="acme_corp",
    collection="default",
    app_knowledge=json.dumps([
        {
            "database": "acme_corp",
            "collection": "default",
            "id": "auth-controls-001",
            "kind": "knowledge_base",
            "fields": {
                "kind": "knowledge_base",
                "title": "Authentication controls",
                "body": "Authentication controls are reviewed quarterly for SOC2.",
            },
            "metadata": {
                "department": "security",
                "priority": 7,
                "summary_label": "quarterly access control review",
            },
            "additional_metadata": {"author": "alice", "doc_version": 3},
        }
    ]),
)

await client.context.ingest({
  type: "knowledge",
  database: "acme_corp",
  collection: "default",
  appKnowledge: JSON.stringify([
    {
      database: "acme_corp",
      collection: "default",
      id: "auth-controls-001",
      kind: "knowledge_base",
      fields: {
        kind: "knowledge_base",
        title: "Authentication controls",
        body: "Authentication controls are reviewed quarterly for SOC2.",
      },
      metadata: {
        department: "security",
        priority: 7,
        summary_label: "quarterly access control review",
      },
      additional_metadata: { author: "alice", doc_version: 3 },
    },
  ]),
});

curl -X POST 'https://api.hydradb.com/context/ingest' \
  -H "Authorization: Bearer $HYDRA_DB_API_KEY" \
  -H "API-Version: 2" \
  -F "type=knowledge" \
  -F "database=acme_corp" \
  -F "collection=default" \
  -F 'app_knowledge=[
    {
      "database": "acme_corp",
      "collection": "default",
      "id": "auth-controls-001",
      "kind": "knowledge_base",
      "fields": {
        "kind": "knowledge_base",
        "title": "Authentication controls",
        "body": "Authentication controls are reviewed quarterly for SOC2."
      },
      "metadata": {
        "department": "security",
        "priority": 7,
        "summary_label": "quarterly access control review"
      },
      "additional_metadata": {
        "author": "alice",
        "doc_version": 3
      }
    }
  ]'

Query with metadata filters: Python, TypeScript, or cURL

Wait for GET /context/status to report completed for auth-controls-001 in the default collection before running this query.Top-level keys filter on metadata. Keys nested under additional_metadata filter on the free-form layer. Both can appear in one request.

result = client.query(
    database="acme_corp",
    collection="default",
    query="How do access control reviews work?",
    type="knowledge",
    metadata_filters={
        "department": {"equals": "security"},
        "priority": {"equals": 7},
        "additional_metadata": {"author": "alice"},
    },
)

const result = await client.query({
  database: "acme_corp",
  collection: "default",
  query: "How do access control reviews work?",
  type: "knowledge",
  metadataFilters: {
    department: { equals: "security" },
    priority: { equals: 7 },
    additional_metadata: { author: "alice" },
  },
});

curl -X POST 'https://api.hydradb.com/query' \
  -H "Authorization: Bearer $HYDRA_DB_API_KEY" \
  -H "API-Version: 2" \
  -H "Content-Type: application/json" \
  -d '{
    "database": "acme_corp",
    "collection": "default",
    "query": "How do access control reviews work?",
    "type": "knowledge",
    "metadata_filters": {
      "department": { "equals": "security" },
      "priority": { "equals": 7 },
      "additional_metadata": { "author": "alice" }
    }
  }'

What each property means

Property	What it is
`database_metadata_schema`	The fields a source’s `metadata` may carry, each with a `name` and a `data_type`. The schema field reference lists every option.
`enable_dense_embedding`, `enable_sparse_embedding`	Make a `VARCHAR` field searchable as text: dense adds semantic search, sparse adds keyword (BM25) search. Put the concept in `query`, not in `metadata_filters`.
`metadata` on the item	Values for the declared fields. Each value must match the declared type, and an undeclared key is rejected when the database has a schema. Up to 16 KiB per item.
`additional_metadata` on the item	Free-form fields with no schema. Up to 1 KiB per item.
`metadata_filters`	Hard constraints applied before ranking. Top-level keys take an operator object such as `{"equals": "security"}`; keys under `additional_metadata` take a bare value. Every key must match. Filter operators covers the forms.

A valid filter that matches no source returns an empty result. HydraDB does not widen it into an unfiltered search.

2. The two layers

Layer	Sent at ingest as	Query filter shape	Best for
Database metadata	`metadata`	Top-level keys in `metadata_filters`	Fields you filter on often, such as department, region, plan, customer, or status. Declare their names and types in `database_metadata_schema`.
Additional metadata	`additional_metadata`	Nested under `metadata_filters.additional_metadata`	Free-form per-source fields for display, citations, debugging, external IDs, or occasional filters. No schema.

A filter runs in three steps:

HydraDB resolves the metadata and additional_metadata filters to the matching source IDs.
It runs vector and keyword retrieval only over those sources.
It rechecks every retrieved passage against the filter. The recheck also keeps graph expansion and retry paths from leaking excluded sources.

An additional_metadata filter that cannot be resolved up front is checked after retrieval, with about 3x over-fetch to compensate. A few fields worth declaring from the start:

status: tag every source draft or published, and send {"status": {"equals": "published"}} on user-facing queries to keep work in progress out of customer answers.
language: route each query to its language with a filter on the detected language.

For a company brain, filters do the isolation inside one collection: put a team, region, or user id in metadata and filter on it in each query. Use separate collections only for data that must never meet in one search.

3. Filter operators

Each top-level key in metadata_filters takes an operator object naming the comparison:

Operator	Value	Matches
`equals`	a single value	sources whose field is exactly that value
`contains`	a single value	sources whose field holds that value, at any position in a multi-value field
`contains_any`	an array	sources holding any one of the listed values (OR, like IN)

equals works on every declared type, so {"priority": {"equals": 7}} is valid on an INT64 field. contains, contains_any, and arrays need a VARCHAR field; sent for a declared field of another type, they are rejected with 400.

Operator forms, and what each returns

{
  "metadata_filters": {
    "department": { "equals": "legal" },
    "attendee_emails": { "contains": "[email protected]" },
    "tags": { "contains_any": ["alpha", "beta"] }
  }
}

Given four sources with these attendee_emails values:

Source	`attendee_emails`
A	`[email protected]`
B	`[email protected],[email protected]`
C	`[email protected]`
D	`[email protected],[email protected],[email protected]`

Filter	Returns
`{"equals": "[email protected]"}`	A
`{"contains": "[email protected]"}`	A, B, D
`{"contains_any": ["[email protected]", "[email protected]"]}`	A, B, C, D

Behavior	Contract
Multiple keys	AND. Every key you send must match, across both layers.
`equals`	Exact equality against the whole stored value.
Lists	ANY, not ALL. `{"contains_any": ["alpha", "beta"]}` matches a source tagged `alpha` and a source tagged `beta`. Adding values widens the result set; there is no ALL operator inside a single key.
OR	Within one key, use `contains_any`. Across different keys, run several queries and union the results yourself.
Null values	Rejected with `400` (`metadata_filters values cannot be null`).
Range and fuzzy	Not supported. Put the concept in `query`, use a searchable `VARCHAR` field, or post-process in your application.
Graph context	Respects the filter; graph paths from excluded sources are removed.
Size	At most 500 values per list, and 64 KiB for the whole `metadata_filters` object. See filter size limits.

Filtering additional_metadata: operators apply to top-level keys only. Inside additional_metadata, use a bare value for an exact match or an array to match any listed value. An operator placed there is not rejected; it is read as an exact match against a stored object, so the query returns 200 with an empty result. What returns 400, and what does not: a known operator with the wrong value type, several operators in one object, or a null value is rejected with 400. A misspelled operator, such as {"contian": "x"}, is not rejected; it is read as a filter for a stored object with that key and matches nothing. Reserved key names: equals, contains, and contains_any are read as operators. This only matters for a JSON field that stores an object whose keys are all drawn from those words: {"contains": "x"} is read as the operator, {"contains": "a", "equals": "b"} is rejected with 400, and {"contains": "a", "other": 1} stays an ordinary exact-match filter. To match such an object, rename the nested key or the field. Bare forms: filters without an operator still work but are deprecated, because the comparison is inferred from the JSON shape. A bare value behaves as equals, a bare array as contains_any, and a one-element array as contains, so {"emails": "a@x"} and {"emails": ["a@x"]} return different results. document_metadata is still accepted as a legacy alias for additional_metadata; when both are present, additional_metadata wins on conflicts.

Store several values in one field

A declared schema field holds a single value. To store several values in one field, declare it as VARCHAR and join the values with commas, then filter for one member with contains.

Store comma-joined values and filter for one member

At ingest:

{
  "metadata": {
    "attendee_emails": "[email protected],[email protected]"
  }
}

At query:

{
  "metadata_filters": {
    "attendee_emails": { "contains": "[email protected]" }
  }
}

data_type: "array" is not accepted on a declared field: declaring one is rejected with 400.
An array value for a declared VARCHAR field is also rejected: metadata field "attendee_emails" must be of type string, got array. Join the values yourself.
The comma is the separator: a value that itself contains a comma will not match as expected. Use a field per value, or a different value format, if your values can contain commas.
Size the field for the whole joined string: max_length defaults to 1024, its maximum is 65535, and it cannot be raised after the field is created, so declare it large enough up front.
equals compares the entire joined string: it is rarely what you want on a multi-value field. Use contains.

4. Size limits

Stored metadata

Every request that attaches metadata is checked against two caps, on ingest and on metadata edit alike:

Layer	Send as	Cap
`metadata`	`metadata` at ingest, `database_metadata` on edit	16 KiB (16,384 bytes)
`additional_metadata`	`additional_metadata`	1 KiB (1,024 bytes)

Older spellings are still accepted, but which one works depends on the endpoint:

Alias	On `/context/ingest`	On `PATCH /context/{id}/metadata`
`tenant_metadata`	accepted	accepted (`database_metadata` wins if both are sent)
`document_metadata`	accepted	rejected with `400`: send `additional_metadata`

Accepted aliases have the same cap as the canonical field. The cap applies to the whole map, not to any one value, and it is measured on the map’s compact JSON encoding in UTF-8 bytes. Three consequences:

Keys and punctuation count: quotes, colons, commas, and braces all count toward the byte limit.
Bytes, not characters: accented Latin characters cost 2 bytes, most CJK characters 3, and emoji 4.
Budget in bytes from the start: a 950-character summary sounds comfortably under a 1 KiB cap, but with two small sibling keys it serializes to 1,015 bytes (65 bytes of that is structure alone). Push the summary to 1,000 characters and the request is rejected at 1,065 bytes.

Exceeding either cap fails the whole request with 400 before anything is ingested. The message names the offending field and reports both numbers. On PATCH /context/{id}/metadata the same message is prefixed with invalid metadata edit:.

A map just inside the 1 KiB cap, and the 400 it returns when it grows

Document metadata: 1,015 bytes, just inside the 1 KiB cap

{"title":"Q3 Board Deck","author":"[email protected]","summary":"<950 characters>"}

{
  "success": false,
  "data": null,
  "error": {
    "code": "INVALID_INPUT",
    "message": "additional_metadata is too large (1065 bytes when serialized; the maximum is 1024). Reduce the number or size of metadata fields."
  }
}

If a document needs more than 1 KiB of descriptive metadata, put the long text in the document body, where it gets chunked and embedded, and keep additional_metadata for the short values you filter on.

Filter size limits

metadata_filters on /query has its own pair of caps. They bound what you send at query time, not how much metadata a source carries:

Limit	Cap
Values in any one list	500
Whole `metadata_filters` object	64 KiB (65,536 bytes)

Both are measured the same way as the stored caps: compact JSON, UTF-8 bytes, field names and punctuation counted. The object total includes the nested additional_metadata object, and it is measured after operator objects are reduced to their values, so {"contains": "x"} counts as ["x"] and the operator keyword costs nothing. Both limits exist because every value in a list is expanded into the filter expression sent to the vector store. The per-list cap catches one runaway list; the object cap catches many individually legal lists adding up. Twenty lists of 500 values are each within the element cap but total roughly 127 KiB, so the object cap is what rejects them. Exceeding either limit returns 400 before the query runs, naming the offending key or the actual byte count.

The 400 messages for an oversized filter

metadata_filters.customer_id (got 743) must contain at most 500 values

metadata_filters is too large (130251 bytes when serialized; the maximum is 65536).
Reduce the number or size of filter values.

Needing far more than 500 values in one filter usually means the constraint belongs in the data rather than the query: add a metadata field that groups those values (a segment, tier, or cohort key) and filter on that instead.

5. Add schema fields later

PATCH /databases/{database}/metadata-schema adds fields to an existing database. It is additive only: fields are added, never deleted, retyped, or reflagged. The response returns added_fields directly, without the success and data envelope, and a field you resend with an identical definition is skipped.

Add a status field to an existing database: Python, TypeScript, or cURL

client.databases.update_metadata_schema(
    "acme_corp",
    add_fields=[{"name": "status", "data_type": "VARCHAR", "max_length": 32}],
)

await client.databases.updateMetadataSchema({
  database: "acme_corp",
  addFields: [{ name: "status", dataType: "VARCHAR", maxLength: 32 }],
});

curl -X PATCH 'https://api.hydradb.com/databases/acme_corp/metadata-schema' \
  -H "Authorization: Bearer $HYDRA_DB_API_KEY" \
  -H "API-Version: 2" \
  -H "Content-Type: application/json" \
  -d '{
    "add_fields": [
      { "name": "status", "data_type": "VARCHAR", "max_length": 32 }
    ]
  }'

Plan the schema before your first ingest:

Searchable fields are declared at creation: fields added later cannot turn on dense or sparse search; the endpoint rejects enable_dense_embedding and enable_sparse_embedding.
Existing fields are fixed: renaming a key means re-ingesting the affected sources, or creating a new database with the corrected schema.
Undeclared keys match nothing: a database with a schema rejects undeclared metadata keys on ingest and on edit, so no source ever holds them, and a filter on such a key returns nothing. The exceptions are connector_id and provider, which connectors write on every synced object. If you will filter on a field more than once, declare it.

6. Update metadata without re-ingesting

Use PATCH /context/{id}/metadata when you know the source ID and need to change its metadata in place. The body uses database_metadata for the schema-backed layer (the shorter metadata spelling from ingest is not accepted here) and additional_metadata for the free-form layer.

Change a source's department and author: Python, TypeScript, or cURL

client.context.update_source_metadata(
    "auth-controls-001",
    database="acme_corp",
    collection="default",
    database_metadata={"department": "legal"},
    additional_metadata={"author": "grace"},
)

await client.context.updateSourceMetadata({
  id: "auth-controls-001",
  database: "acme_corp",
  collection: "default",
  databaseMetadata: { department: "legal" },
  additionalMetadata: { author: "grace" },
});

curl -X PATCH 'https://api.hydradb.com/context/auth-controls-001/metadata' \
  -H "Authorization: Bearer $HYDRA_DB_API_KEY" \
  -H "API-Version: 2" \
  -H "Content-Type: application/json" \
  -d '{
    "database": "acme_corp",
    "collection": "default",
    "database_metadata": { "department": "legal" },
    "additional_metadata": { "author": "grace" }
  }'

The source must already exist: this endpoint does not create sources, and collection is required.
At least one of database_metadata, additional_metadata, or acl is required: tenant_metadata is a deprecated alias for database_metadata; document_metadata is rejected.
Metadata merges: sent keys are inserted or overwritten; omitted keys are preserved. acl is the exception: when sent, it replaces the stored list, and an acl-only body is a valid edit. See Access Control.
The edit is visible to filters and listing right away: if no edited field has an embedding flag, the vector store is untouched and the response reports vector_sync_required: false.
Searchable fields sync synchronously: if an edited field has enable_dense_embedding or enable_sparse_embedding, HydraDB refreshes that field’s search lane and reports vector_sync_required and vector_synced in the response (the milvus_sync_required and milvus_synced aliases are still emitted, deprecated). Such a field rejects null, because it would leave stale metadata vectors behind.

To replace a source’s content as well as its metadata, re-ingest it with upsert: true and the same source id. Upsert replaces the source payload and the metadata supplied by ingestion.

7. List sources with metadata filters

Use POST /context/list to browse or page sources rather than run semantic retrieval. Its filters object takes metadata, additional_metadata, and source_fields, each as bare key-value pairs. source_fields filters on the source’s own fields: title, type, description, url, timestamp, and for app sources app_provider, app_kind, app_external_id, and app_parent_id. Pair app_external_id or app_parent_id with app_provider, because a Jira issue key and a Linear ID can collide.

List legal sources by Alice from Slack: Python, TypeScript, or cURL

from hydra_db import ListContentFilter

result = client.context.list(
    database="acme_corp",
    collection="default",
    type="knowledge",
    filters=ListContentFilter(
        metadata={"department": "legal"},
        additional_metadata={"author": "alice"},
        source_fields={"app_provider": "slack"},
    ),
)

const result = await client.context.list({
  database: "acme_corp",
  collection: "default",
  type: "knowledge",
  filters: {
    metadata: { department: "legal" },
    additionalMetadata: { author: "alice" },
    sourceFields: { app_provider: "slack" },
  },
});

curl -X POST 'https://api.hydradb.com/context/list' \
  -H "Authorization: Bearer $HYDRA_DB_API_KEY" \
  -H "API-Version: 2" \
  -H "Content-Type: application/json" \
  -d '{
    "database": "acme_corp",
    "collection": "default",
    "type": "knowledge",
    "filters": {
      "metadata": { "department": "legal" },
      "additional_metadata": { "author": "alice" },
      "source_fields": { "app_provider": "slack" }
    }
  }'

/context/list also accepts the legacy aliases tenant_metadata for metadata and document_metadata for additional_metadata; the current name wins on conflicts. It takes the same acl field as /query to list as one person. See Access Control.

Schema field reference

Each entry in database_metadata_schema on Create Database, and in add_fields on Update Metadata Schema, takes these options:

Field	Type / values	Purpose
`name`	string	Metadata key. Must start with a letter, contain only letters, numbers, and underscores, and not use a reserved system name such as `source_id`, `chunk_id`, or `metadata`.
`data_type`	`VARCHAR`, `BOOL`, `INT8`, `INT16`, `INT32`, `INT64`, `FLOAT`, `DOUBLE`, `JSON`, or the friendly aliases `string`, `boolean`, `integer`, `float`, `object`	Defaults to `VARCHAR`. `ARRAY` is not supported and is rejected with `400`; for multi-value fields see Store several values in one field.
`max_length`	integer	Maximum length for a `VARCHAR` value. Default `1024`, maximum `65535`. This sizes one declared field; it is not the limit on how much metadata you can send per request, which is in Size limits.
`enable_dense_embedding`	boolean	Adds semantic search over a `VARCHAR` field.
`enable_sparse_embedding`	boolean	Adds keyword (BM25) search over a `VARCHAR` field.

Limits:

Up to 32 custom metadata fields per database.
Up to 6 embedding-enabled fields per database: enable_dense_embedding and enable_sparse_embedding each count as one, so a field with both set counts as two. Exceeding the limit fails database creation with 400 before anything is provisioned.
Field names are unique case-insensitively.
Embedding flags are only valid on VARCHAR fields.
Values must match the declared type when the database has a schema.
Unknown metadata keys are rejected on ingest and edit when the database has a non-empty schema.
Each metadata layer has a byte budget per request; see Size limits.

Common mistakes

Symptom	Cause	Fix
`metadata_filters` returns no results	The key is not declared in `database_metadata_schema`, so no source holds it (undeclared keys are not ignored)	Add the field with `PATCH /databases/{database}/metadata-schema` and ingest or edit sources with a value, or move the field to `additional_metadata` and nest the filter under `additional_metadata`.
A filter on an `additional_metadata` key returns nothing	The key was sent top-level, so it was matched against `metadata`	Nest it: `metadata_filters: { additional_metadata: { author: "alice" } }`.
Schema field changes do not take effect	Existing schema fields cannot be renamed, retyped, reflagged, or deleted; you can only add fields	Create a new database with the corrected schema. There is no in-place migration for existing fields.
Query returns 0 results after adding a filter	Over-filtering: the combined constraints exclude everything	Start with the minimum hard constraints; add filters one at a time and re-check counts.
A range or fuzzy filter does not work	`metadata_filters` supports only `equals`, `contains`, and `contains_any`	Move that constraint into the `query` text, or apply it in your own post-processing.
An `additional_metadata` filter feels slow	When it cannot be resolved up front, it over-fetches about 3x to compensate for post-retrieval matching	Move the hot field into `metadata` and declare it in the schema.
Metadata edit returns `400`	Unknown key, wrong type, oversized payload (16 KiB database metadata or 1 KiB document metadata), too-deep nesting, reserved key, or missing `collection`	Check the schema and size limits; send only `database_metadata`, `additional_metadata`, or `acl`.
A dense or sparse metadata edit rejects `null`	Null would leave stale semantic metadata vectors	Set a non-null value or re-ingest with the desired metadata.
Need a semantic or keyword metadata field after creation	The schema update endpoint rejects dense and sparse flags	Declare those fields at database creation, or re-ingest into a new database with the final schema.

Knowledge: what attaches to knowledge sources
Memories: metadata fields on memory items
Multi-tenancy: partitioning with collections, which filters do not replace
Query: how metadata_filters interacts with ranking
Access Control: restricting who may retrieve a document, which is not a metadata filter
Create Database (API Reference): full database_metadata_schema reference
Query (API Reference): full metadata_filters reference
List Context (API Reference): source browsing filters
Update Source Metadata (API Reference): point metadata edits
Update Metadata Schema (API Reference): additive database schema changes

Get Started

Usage

Organize

Understand

Plugins

For Agents

1. Declare a field and filter on it

What each property means

2. The two layers

3. Filter operators

Store several values in one field

4. Size limits

Stored metadata

Filter size limits

5. Add schema fields later

6. Update metadata without re-ingesting

7. List sources with metadata filters

Schema field reference

Common mistakes

​1. Declare a field and filter on it

​What each property means

​2. The two layers

​3. Filter operators

​Store several values in one field

​4. Size limits

​Stored metadata

​Filter size limits

​5. Add schema fields later

​6. Update metadata without re-ingesting

​7. List sources with metadata filters

​Schema field reference

​Common mistakes

​Related

1. Declare a field and filter on it

What each property means

2. The two layers

3. Filter operators

Store several values in one field

4. Size limits

Stored metadata

Filter size limits

5. Add schema fields later

6. Update metadata without re-ingesting

7. List sources with metadata filters

Schema field reference

Common mistakes

Related