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 make it easier to manage observability data at scale, especially when you need:

• Policy consistency: Apply routing, retention, and enrichment at the group level.

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

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:

• alerts.history – triggered alerts and metadata
• engine.queries – history of alert events
• engine.schema_fields – snapshots of schema evolution
• notification.deliveries – notification tracking
• notification.requests – notification tracking

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

Learn more

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