Dataspaces

What is a dataspace?

A dataspace is a logical container for one or more datasets. It defines shared configurations and access boundaries across those datasets.

Each dataspace acts as a control layer for:

• Routing logic
• Storage structure
• Retention policies
• Access control
• Schema enforcement

You query datasets with DataPrime inside a dataspace using:

source <dataspace>/<dataset>

Why use dataspaces?

Dataspaces act as containers for organizing related datasets. They make it easier to manage access policies, routing rules, and storage settings, especially in multi-team, multi-environment, or multi-tenant setups.

Dataspaces make it easier to manage observability data at scale, especially when you need:

• Policy consistency: Apply routing, retention, and enrichment at the group level.
• Separation of concerns: Isolate data by team, environment, or function.
• Simplified access control: Grant users access to an entire dataspace rather than individual datasets.
• Forward-compatible design: Automatically extend policies to new datasets as they are created.

Use dataspaces to:

• Group datasets by team, environment, or function
• Apply consistent routing and retention rules to all datasets in a space
• Automatically inherit access policies and storage paths
• Support dynamic dataset creation with names like alerts.prod, rum.east, or teamX.errors
• Keep internal datasets (e.g., audit logs, query logs) separate from product telemetry

Dataspaces are ideal when your organization needs logical isolation, policy enforcement, and scalable data lifecycle management—all without manually managing each dataset.

How configuration inheritance works

When a dataset is created inside a dataspace, it automatically inherits the dataspace's configuration, such as:

• S3 storage paths
• Retention rules
• Access policies
• Metadata enrichment

For example, if a dataspace defines this S3 path:

s3://my-bucket/my_prefix

Then new datasets inside that dataspace will automatically write to:

s3://my-bucket/my_prefix/dataset1
s3://my-bucket/my_prefix/dataset2
s3://my-bucket/my_prefix/dataset3

This inheritance is dynamic — no manual setup is needed when new datasets appear.

Data flow with dataspaces

The end-to-end journey looks like this:

1. Ingestion

   Logs, metrics, spans, and events are ingested into Coralogix.

2. Routing

   The TrafficProcessor applies routing rules to determine the appropriate dataset and dataspaces. For example, routing events to default.{{$d.region}}-events will create a separate dataset for each region encountered in the data. Data is distributed across multiple destinations accordingly.

3. Dataset creation

   New datasets are created automatically inside the target dataspace.

4. Configuration application

   Each dataset inherits settings from the parent dataspace including:

   • Storage destination
   • Retention policies
   • Access controls
   • Enrichment rules

5. Final storage and access

   Data is stored according to blueprint paths (e.g., s3://bucket/prefix/dataset-name) and made available for search, visualization, and alerting.

Types of dataspaces

Coralogix supports three kinds of dataspaces:

Type	Description
default	The main user-facing dataspace. Contains DataSets like logs, spans, and others unless specified.
system	A Coralogix-managed dataspace for internal datasets such as alert history, audit events, and schema metadata.
user-defined	forthcoming feature: Custom dataspaces created by users to segment data by team, region, environment, or use case.

The default dataspace

All user data flows into default unless routed elsewhere. Common datasets include:

source default/logs
source default/spans
source default/<custom-enrichment>

Shortcut behavior:

If you don’t specify a dataspace, default/ is assumed.

These are all equivalent:

source logs
source default/logs
// or even just:
| filter status_code >= 500

If you're only using default, there's no need to change your query syntax.

The system dataspace

The system dataspace contains internal datasets populated and maintained by Coralogix. These include:

• aaa.audit_alerts – snapshots of schema evolution
• alerts.history – triggered alerts and metadata
• cases – historical record of incidents and their outcomes
• engine.queries – history of alert events
• engine.schema_fields – snapshots of schema evolution
• labs.limit_violations – records of each time a limit is exceeded
• notification.deliveries – notification tracking
• notification.requests – notification tracking

The data is read-only and structured for analysis via Explore and Custom Dashboards.

User-defined dataspaces

You can create your own dataspaces to match the structure of your organization. Common examples include:

• prod/ for production data
• dev/ for development logs
• marketing/, security/, or team-alpha/ for team-specific pipelines

Each of these can contain logs, spans, metrics, and more — all governed by their parent dataspaces rules.

Learn more

• Overview of datasets
• Overview of the default dataspace
• Overview of the system dataspace