On This Page

Home / Search/ Manage/Cribl Search Engines

Cribl Search Engines

Understand engines that power Cribl Search and how to size them for your environment.

Cribl Search Engine Types
​

Cribl Search gives you two main compute surfaces:

  • Lakehouse, where you ingest and store data in Cribl Search for the fastest, most guided experience.
  • Federated Search, where you query data in place in external systems like S3 or Lake/Lakehouse.

Engines are how you size those surfaces:

  • Lakehouse engines control how much data you can ingest, store, and search in a given Workspace.
  • The federated engine (federated compute) controls how much federated search capacity you provision at the Workspace level.

What’s an Engine
​

An engine is a resource Cribl Search uses to run queries.

  • Lakehouse engines provide both storage and compute for data you ingest into Cribl Search. You can provision multiple lakehouse engines per Workspace.
  • The federated engine provides compute only, for search-in-place over data that stays in external systems. Each Workspace has a single, globally sized federated engine.

You manage the federated engine from the same place as lakehouse engines, in Cribl Search, select Data > Engines.

For a glossary-level view, see Cribl Search Concepts.

Lakehouse engines
​

A lakehouse engine is a storage-plus-compute unit that backs Get Your Data In and lakehouse Datasets.

When you route data into Cribl Search with Sources, it is parsed by Datatypes and stored in Lakehouse Datasets that live directly on a lakehouse engine.

Each lakehouse engine:

  • Accepts data from one or more Sources.
  • Uses Datatypes to break events into fields.
  • Stores data in Lakehouse Datasets until their retention expires.
  • Powers fast, schema-aware searches and AI workflows over that stored data.

From a sizing perspective, you control two things:

  • Lakehouse engine size (per engine): How much uncompressed data per day that engine is designed to ingest.
  • Retention period (per Dataset): How long to keep the data on that engine.

For details on how lakehouse engines work, which sizes are available, and how to add or resize them, see:

Federated Engine
​

The federated engine is a Workspace-wide compute tier for federated search.

Federated Search runs queries directly against external storage such as S3, Blob, or Lake/Lakehouse, without ingesting that data into lakehouse engines. Instead of creating multiple federated engines, each Workspace has a single federated engine with a configurable size.

The federated engine:

  • Applies to all federated searches in the Workspace.
  • Does not store data, it provides compute for search-in-place.
  • Is independent of any lakehouse engine you configure.

What Federated Size Controls
​

When you set a federated size, you are making a Workspace-level choice about how much federated search capacity you intend to use. That choice:

  • Acts as a capacity and entitlement signal for federated workloads.
  • Is visible to Cribl billing, so your federated usage is interpreted in the context of the size you selected.

The federated size is not a hard rate limiter by itself. You can think of it as:

  • A way to align how heavily you expect to use federated search with how your account is configured and billed.
  • A unit that’s simple enough to choose in the UI, while exact thresholds and pricing remain governed by your contract and Cribl billing systems.

Changing the federated size:

  • Does not resize any lakehouse engine.
  • Does not change how much Lakehouse data you can ingest or store.
  • Only updates the Workspace-level federated capacity tier.

What You See, Based on Your Billing Model
​

The federated selector behaves differently depending on how you’re billed today.

Search Subscription
​

If you have an existing Search Subscription contract:

  • Your Workspace appears with a federated size of Search Subscription when federated compute is enabled.
  • The selector in Search > Data > Engines is disabled. You cannot change the size or switch to Usage Based from the UI while the subscription is active.
  • You cannot switch to or from Search Subscription using the selector. This state is system-managed based on your contract.

In practice, Search Subscription reflects the federated capacity that your subscription already entitles you to. You continue to use federated search under that contract until it ends.

When the subscription expires, the UI will prompt you to choose:

  • One of the tiered federated sizes, or
  • Usage Based (Pay-as-you-go), which remains available but is discouraged for long-running, high-volume federated workloads because costs can be harder to predict.

Tiered Federated Billing
​

If you are not on a legacy Search Subscription and your account uses tiered federated billing:

  • The federated selector is fully enabled.
  • You can move between fixed sizes within the constraints of your billing plan.

You choose a size based on how central federated is to your environment. Over time, you can revisit that choice as usage patterns become clearer.

Usage-Based Federated Billing
​

If you are billed on usage for federated search:

  • The selector will show Usage Based (Pay-as-you-go) as the active choice initially.
  • You can move from Usage Based into a tiered federated size when you are ready, and back again if your contract allows.

Federated Engine Sizes
​

The federated size selector is intentionally high-level: instead of asking you to reason about internal metrics, it asks you to decide how important federated search is to your day-to-day work and how predictable you want your costs to be.

Depending on your billing plan, you can choose from the following sizes:

  • Tiered Sizes: XSmall, Small, Medium, Large, XLarge, 2-XLarge, 3-XLarge, 4-XLarge, 5-XLarge, and 6-XLarge.
  • Usage Based (Pay-as-you-go): Available for occasional or experimental use, though steady, production-grade usage is steered toward named tiers to prevent unpredictable costs during spikes.
  • Search Subscription: A system-managed state for legacy contracts that entitles you to a fixed capacity.

In general:

  • If federated search is central to how you operate (for example, teams run investigations, dashboards, or scheduled searches against S3 or Lake/Lakehouse every day or week), then a tiered federated size is the right starting point.
  • If federated use is occasional or experimental, starting on Usage Based (Pay-as-you-go) can make sense while you learn how often it will be used, with a plan to move to a tier once usage stabilizes.

When to Change Federated Size
​

Federated sizing is not a one-time decision. You should revisit it when:

  • Federated moves from being an occasional tool to a core part of investigations or reporting for multiple teams.
  • Your Cribl billing/FinOps views show that federated usage has become a steady, high-volume component of your spend.
  • You transition out of a Search Subscription state and want your federated capacity to match your current usage rather than the old contract.