LogScale Repository vs. View: When to Use Each

A repository is where LogScale stores your events and metrics. A view is a virtual layer on top of one or more repositories that presents only the data you want people to search.

Use a repository when you need to decide where data is ingested, stored, parsed, retained, and administered. Use a view when you need a different search scope, access boundary, or operational perspective without copying the underlying data.

Store data in repositories. Organise how people search and access it with views.

What is a LogScale repository?

A repository is the main data container in LogScale. Logs and metrics are ingested, parsed, indexed, and retained there.

From my experience, it makes sense to use a separate repository whenever your data needs to be handled differently. For example, you might have different rules for production and test data, or you want to keep customer data separate.

• production versus non-production data
• separate customers or business units
• security telemetry versus application logs
• data with different retention requirements
• data that must be managed by different administrative teams

For example, you might create separate repositories for:

Repositories are also the place where ingestion starts. Your collectors, APIs, ingest tokens, and parsers ultimately send and process data in a repository.

This makes a repository a data lifecycle decision, not merely an organisational folder.

What is a LogScale view?

A view doesn’t make another copy of your data. Instead, it just gives you a new way to look at the data you already have, even if it’s spread across different repositories.

LogScale documents views as a way to group events from repositories, filter events, limit access for specific users, or search multiple repositories together. Manage Repositories and Views — LogScale Documentation

In my experience, views are helpful in two main situations:

1. Combine data from multiple repositories for one investigation workflow.
2. Narrow data from a repository so a team sees only the events relevant to its job.

For example, a security operations team may need to investigate an incident across:

• identity-provider logs in identity
• firewall events in network-security
• endpoint telemetry in edr
• application audit events in prod-app

Instead of requiring analysts to switch repositories or maintain a long multi-repository search, create a security-operations view that includes the relevant sources.

The analysts can then start their investigation from one consistent search context.

Repository vs. view at a glance

A view is therefore not a lighter repository. It solves a different problem.

When to create a separate repository

Create a new repository when the data itself needs a separate operational boundary.

1. Different ingestion or parsing ownership

Use separate repositories when different teams own the sources, parser maintenance, or ingest configuration.

For example:

• the platform team owns Kubernetes and infrastructure telemetry;
• the application team owns application logs;
• the security team owns identity and endpoint telemetry.

A shared repository can work for small environments. But as source volume, ownership, and parser complexity grow, it can become difficult to manage safely and predictably.

2. Different retention or storage requirements

Retention requirements should influence repository design.

Security audit events may need longer retention than verbose debug logs. A staging environment may only need a short troubleshooting window. Keeping both in one repository can turn a clear policy decision into an uncomfortable compromise.

Do not create separate repositories only because data looks different. Create them because the data has a different lifecycle, owner, access model, or operational purpose.

3. Strong tenant or environment separation

Repositories are often a good fit for clear isolation boundaries:

• production vs. staging
• customer A vs. customer B
• internal telemetry vs. externally accessible telemetry
• regulated workloads vs. general application logs

This makes access reviews and operational ownership easier to explain.

When a view is the better choice

Create a view when the data is already in the right repositories, but users need a better way to search or access it.

1. One investigation needs multiple repositories

This is the most common reason to create a view.

An incident rarely stays within one data source. A suspicious sign-in may lead to endpoint events, network connections, cloud audit events, and application actions. A view can group the repositories needed for that investigation.

Example views:

• security-operations
• production-troubleshooting
• customer-support
• platform-observability

This gives teams a focused starting point without moving or duplicating data.

2. A team needs only part of a repository

A repository may contain data useful to several teams, but not every event should be part of every team’s working context.

For example, an application repository might contain:

• request logs
• job-worker logs
• authentication events
• billing events
• internal debug messages

A support team may only need customer-facing request and authentication events. A view can expose that operationally relevant subset, reducing noise and making saved searches and dashboards more useful.

This is also valuable when a view is used to provide a more limited access scope for a specific group. LogScale supports separate users, permissions, dashboards, and saved queries for repositories and views. Repositories, Views, and Parsers — LogScale Training

3. You want a stable operational workspace

Views are useful when a team’s questions stay consistent even while the underlying data sources evolve.

For example, your production-troubleshooting view might initially include:

• prod-app
• prod-kubernetes
• prod-database

Later, you add an API gateway repository. The team can keep using the same view, dashboards, and saved searches while the underlying search scope grows.

That is a useful abstraction: the operational workspace remains stable, while the implementation can change.

A practical design pattern

For many teams, this structure works well:

Repositories
├── prod-app
├── prod-platform
├── prod-security
├── staging-app
└── customer-audit

Views
├── production-troubleshooting
├── security-operations
├── application-team
└── customer-support

The repositories reflect how data is collected and governed.

The views reflect how people investigate and operate.

This avoids two common mistakes:

1. Creating a repository for every dashboard or team.
2. Putting all data into one repository and expecting every team to filter it correctly in every search.

Avoid using views as a substitute for data design

Views are powerful, but they do not replace repository design.

A view does not create independent storage, retention, parser ownership, or ingestion configuration. It works with data that already exists in repositories. LogScale explicitly notes that views do not store their own data. Repositories — LogScale Training

If you need a hard separation because of tenancy, compliance, ownership, retention, or ingest architecture, start with separate repositories.

If you already have the right data boundaries and want to improve search usability or scoped access, add views.

Decision checklist

Create a repository if you answer yes to any of these questions:

• Does this data need a different retention or storage policy?
• Does another team own ingestion or parser maintenance?
• Is this a separate tenant, environment, or governance boundary?
• Do we need to manage access to the raw dataset independently?
• Would combining this data with existing data make administration harder?

Create a view if you answer yes to any of these questions:

• Does one team need to search across multiple repositories?
• Does a team need only a filtered operational subset of existing data?
• Do we want a stable workspace for dashboards and saved searches?
• Can we solve the problem without copying or re-ingesting data?
• Is the need about how users work with data rather than how data is stored?

Final recommendation

Begin with repositories that reflect real data boundaries: ownership, ingestion, retention, environment, tenancy, and governance. Then create views for users such as security analysts, platform engineers, application teams, and support staff. A well-structured repository keeps data manageable, while effective views enhance usability.

Before creating a new repository, note its owner, ingestion sources, retention requirements, and intended users. If the data boundary is already correct and only the search scope or working context differs, create a view first.