Satlyt, CedarDB, and the non GPU bottleneck

What changed at Startup Battlefield 2026

TechCrunch published its Startup Battlefield 2026 Top 20 on October 13, 2026, and updated the list on October 23. Two entries are especially relevant to operators of small and mid-size GPU estates. Satlyt was highlighted for satellite-based AI compute. CedarDB was highlighted for an AI-native data layer.

The important point for infrastructure teams is not that satellites or databases are new. It is that both examples move the bottleneck away from the simple question of how many GPUs are available. Satlyt points to compute that may be remote, bandwidth constrained, latency sensitive, or intermittently connected. CedarDB points to AI workloads where retrieval, transactional consistency, storage layout, CPU scheduling, and database memory can determine whether GPUs are fed or left idle.

For an operator running a quarter rack to a few racks, this matters immediately. A small GPU estate cannot absorb waste the way a hyperscaler region can. If a tenant pins a full GPU for a notebook that spends most of its time waiting on object storage, the operator loses capacity. If a retrieval workload pushes random reads into the same storage pool used for tenant home directories, latency becomes a shared problem. If model weights, vector indexes, transactional data, caches, and batch jobs are all treated as one undifferentiated AI workload, chargeback becomes political rather than factual.

ClastIQ is designed for this class of operator: real hardware, local control, mixed CPU and GPU fleets, Kubernetes and VM tenancy on the same estate, MAAS and Juju based bare-metal provisioning, Ceph storage, GPU partitioning, quotas, policy, metering, chargeback, air-gap operation, and human-led local support. The lesson from Satlyt and CedarDB is that orchestration has to include the data path, not only the accelerator.

The bottleneck is no longer only GPU allocation

A common first phase for a small GPU cluster is simple scheduling. Give each tenant a VM or namespace. Attach one or more GPUs. Add a shared storage mount. Meter GPU-hours. That works until the workloads diversify.

Satellite-based AI compute changes assumptions about locality. A remote sensor, industrial site, vessel, aircraft, or orbital compute node may not be able to stream all data back to a central cluster. Inference may need to run close to the source, then synchronize summaries, embeddings, model deltas, or selected raw data later. The central estate still matters, but it becomes part of a distributed control plane. Jobs must tolerate disconnection. Data must be staged. Policies must define what can move, what must stay local, and which tenant pays for synchronization and storage.

AI-native databases change a different assumption. Retrieval augmented generation, vector search, multimodal catalogs, feature stores, and transactional AI applications spend significant time outside the GPU. They use CPU cycles, RAM, SSD IOPS, network bandwidth, database locks, object metadata, and storage replication. A GPU may be allocated, but the critical path is a database scan, vector index rebuild, cache miss, or checkpoint write.

For a GCC or MENA operator, both patterns are practical rather than theoretical. Regional operators often support energy, logistics, public sector, telecom, research, and financial services workloads. Some data is generated at remote facilities, ports, plants, or edge locations. Some data has sovereignty or contractual restrictions. Some tenants need air-gapped environments. Cloud bursting may be limited by policy, latency, data export rules, or cost predictability. In that setting, the operator has to make a local estate behave like a small region, with clear tenancy, measured usage, and governed movement of data.

Separate weights, indexes, caches, and tenant compute

The first operational mistake is to place every AI artifact in the same storage and scheduling class. Model weights, vector indexes, transactional data, caches, notebooks, batch outputs, and tenant home directories have different performance and governance requirements.

Model weights are usually large, read-heavy, and shared across jobs. They benefit from local caching, content addressing, immutability, and careful replication. A 70 billion parameter model can easily occupy well over 100 GB depending on precision and packaging. If ten tenants each pull their own copy from external storage, the operator pays in bandwidth, SSD wear, and startup latency. A better pattern is a controlled model catalog with local mirrors, tenant entitlements, and cache accounting.

Vector and retrieval indexes behave differently. They may be updated regularly, are latency sensitive, and can generate random reads. They need storage placement and CPU reservations as much as GPU access. Transactional data is different again. It needs durability, snapshots, access controls, and sometimes strict locality. Caches are yet another class: high value when hot, disposable when cold, and dangerous if not isolated across tenants.

A practical separation looks like this:

This table is deliberately ordinary. It is not a research architecture. It is the minimum separation needed to keep chargeback credible and utilization high.

How ClastIQ maps this to a small estate

On a quarter rack to a few racks, the control plane must be simple enough to operate locally but strict enough to prevent tenant behavior from damaging the whole estate. ClastIQ addresses this by combining bare-metal provisioning, Kubernetes and VM tenancy, storage policy, GPU partitioning, and metering in one operational model.

Bare-metal provisioning matters because hardware state is part of capacity. Operators need to know which nodes have which GPUs, which CPUs, how much RAM, which NICs, which local drives, which firmware levels, and which tenants or pools they are assigned to. MAAS and Juju provide repeatable deployment and lifecycle control, instead of treating every node as a hand-built server.

Kubernetes and VM tenancy on the same fleet matters because not every AI workload is a container. A database team may need VMs for kernel tuning, licensing, or operational familiarity. A model serving team may need Kubernetes. A research tenant may need notebooks with partitioned GPUs. A security-sensitive tenant may need a more isolated VM. If the operator splits these into separate hardware islands too early, utilization falls. If the operator blends them without policy, noisy neighbors appear.

GPU partitioning matters because many workloads do not need a full accelerator. MIG, where supported, can split a GPU into isolated instances. Time-slicing can improve access for bursty notebooks and low duty cycle inference. Hardware support varies across vendors and generations, so the policy should be hardware-agnostic at the service level: full GPU, fractional GPU, shared GPU, CPU-only, storage-heavy, or database tier. The scheduler then maps that class to available hardware.

Ceph matters because small estates still need durable, shared storage. The question is not whether all workloads should use Ceph. They should not. Hot caches and scratch space may belong on local NVMe. But tenant data, model catalogs, snapshots, and replicated volumes need a governed storage layer with quotas and visibility. The operator should know who is consuming capacity, who is driving IOPS, and which pool is at risk.

Metering and chargeback matter because GPU scarcity creates conflict. A tenant that consumes storage-heavy database resources should not be billed only for GPU time. A tenant that keeps a GPU allocated while waiting on a vector index rebuild should see that inefficiency. A tenant that benefits from a shared model cache should not force everyone else to subsidize it silently.

A worked example: 16 GPUs, data-aware scheduling

Consider a small operator with 16 high-end GPUs in one room, plus CPU nodes, Ceph storage, networking, and power distribution. The annual theoretical GPU capacity is:

16 GPUs x 24 hours x 365 days = 140,160 GPU-hours per year.

Before partitioning and data-aware scheduling, assume average billable utilization is 35 percent. That is common when full GPUs are assigned to notebooks, batch jobs wait for data staging, and tenants reserve capacity ahead of actual work.

140,160 x 0.35 = 49,056 billable GPU-hours.

At an internal or external chargeback rate of $2.60 per GPU-hour, annual GPU revenue or cost recovery is:

49,056 x $2.60 = $127,545.60.

Now introduce three controls. First, split suitable inference and notebook workloads using MIG or time-slicing where the hardware supports it. Second, separate storage-heavy retrieval workloads from GPU-heavy training workloads through quotas and node pools. Third, meter database CPU, storage, and cache usage so tenants stop treating GPU allocation as a reservation system for the whole pipeline.

Assume these controls raise billable GPU utilization to 68 percent without adding GPUs:

140,160 x 0.68 = 95,308.8 GPU-hours.

At the same $2.60 rate:

95,308.8 x $2.60 = $247,802.88.

The improvement is:

$247,802.88 minus $127,545.60 = $120,257.28 per year.

Now add a simple power view. Suppose the GPU estate and its immediate supporting equipment average 18 kW at the wall across the year. Annual energy is:

18 kW x 8,760 hours = 157,680 kWh.

At $0.09 per kWh, annual electricity cost is:

157,680 x $0.09 = $14,191.20.

At 68 percent utilization, electricity per billable GPU-hour is:

$14,191.20 / 95,308.8 = $0.15 per billable GPU-hour, rounded.

If the same room averages 0.018 MW, revenue per MW at the $247,802.88 annual run rate is:

$247,802.88 / 0.018 = $13,766,826.67 per MW-year.

This is not a claim about any ClastIQ deployment or a benchmark. It is a planning example. The point is that utilization and revenue per megawatt improve when the operator stops allocating full GPUs to problems that are actually storage, database, cache, or orchestration problems.

Policy should be visible to tenants

Tenants should not have to guess which resources are scarce or which behavior is expensive. A small operator can publish service classes that map to technical controls.

For example, a tenant running a retrieval augmented generation service may receive a small GPU partition for embedding or reranking, CPU and RAM for the database, a Ceph volume for durable indexes, and a local cache limit for hot documents. A training tenant may receive full GPUs, high write bandwidth for checkpoints, and lower priority on shared vector services. A data preparation tenant may receive CPU and storage without GPU access at all.

A short quota block can make the distinction concrete. The exact resource names depend on the GPU vendor, device plugin, and cluster policy, but the shape is what matters:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-rag-standard
  namespace: tenant-a
spec:
  hard:
    requests.cpu: 64
    requests.memory: 256Gi
    limits.cpu: 96
    limits.memory: 384Gi
    requests.storage: 20Ti
    requests.nvidia.com/mig-1g.10gb: 4
    count/persistentvolumeclaims: 24

That quota says this tenant is not simply a GPU tenant. It is a service with CPU, memory, storage, and fractional GPU boundaries. In a hardware-agnostic estate, the same commercial service class can map to NVIDIA MIG where available, AMD partitioning or scheduling features where applicable, CPU-only pools for preprocessing, or VM based isolation for database nodes.

The operator should pair quota with priority classes and preemption rules. Production inference should not be blocked by a low priority experiment that filled the cache. A sovereign tenant should not share storage pools with a public research namespace if policy forbids it. A database rebuild should not saturate the same network path used for latency-sensitive model serving.

Remote compute needs synchronization policy

Satlyt is a reminder that some compute will not sit neatly inside the main data center. Even if an operator never runs satellite hardware, the pattern applies to remote oil and gas sites, logistics hubs, maritime links, mining operations, defense environments, and rural connectivity across GCC and MENA markets.

The central GPU estate should define what happens when links are slow, expensive, or unavailable. Raw data may stay at the edge. Embeddings may synchronize when bandwidth is available. Model updates may move through an approval process. Inference logs may be sampled rather than streamed. Tenant billing should distinguish local GPU time, central GPU time, storage replication, and network transfer.

This is where air-gap and sovereign deployment capability becomes operationally important. A disconnected environment still needs provisioning, upgrades, image catalogs, identity integration, audit logs, and metering. If the operator cannot run the platform without calling a hyperscaler control plane, it may not meet the requirement. For government, regulated industry, and critical infrastructure in the region, that can decide whether a workload can be hosted locally at all.

ClastIQ's role in this pattern is to give the operator a repeatable way to deploy and govern the estate on owned hardware. Hardware can be mixed. The policies should remain consistent: who can run, where data can live, which accelerators are available, how storage is replicated, what is metered, and how usage is reported.

Database-aware AI changes capacity planning

CedarDB's appearance in the Battlefield list reflects a broader trend: databases are becoming part of the AI execution path, not just a place to store application records. That changes capacity planning for GPU clusters.

A vector search service may need low latency storage and high RAM more than additional accelerators. A transactional AI application may need predictable database commit latency. A multimodal catalog may need object storage throughput and metadata performance. An agentic workflow may generate many small reads and writes while using GPUs only during short inference bursts.

If the GPU operator bills only GPU-hours, these costs disappear from the invoice but not from the infrastructure. Ceph fills up. SSD latency rises. CPU nodes saturate. Network east-west traffic grows. Tenants then ask why their expensive GPU is slow, when the GPU is waiting for data.

The fix is not to make every operator a database vendor. The fix is to schedule databases and data services as first-class tenants. Give them node placement, storage classes, backup policy, CPU and memory reservations, and metering. Then connect those measurements to chargeback. A tenant running a heavy retrieval service should see charges for GPU-hours, vCPU-hours, RAM allocation, storage capacity, snapshots, and possibly IOPS or service tier.

This also helps sales and finance teams. Revenue per megawatt improves when the estate sells the right unit of capacity. A GPU-hour is valuable, but it is not the only product. Storage-heavy AI services, sovereign model hosting, managed inference, database-backed retrieval, and private tenant environments can all be priced more accurately when usage is visible.

GCC and MENA operator implications

For GCC and MENA operators, the local context strengthens the case for this architecture. Data sovereignty is often a requirement, not a preference. Some workloads cannot leave national borders. Some customers want Arabic data, regional document collections, or regulated records hosted under local control. Some sites have excellent metro connectivity, while others depend on constrained links. Power availability, cooling design, and revenue per megawatt are board-level issues.

A small GPU estate can compete only if it is governable. That means an operator can answer basic questions at any time. Which tenant used which GPU, for how long? Which model weights are stored locally, and who is allowed to use them? Which Ceph pool holds regulated data? Which workloads can be evicted? Which jobs are waiting on storage rather than compute? Which customer is profitable after power, storage, and support are included?

The Battlefield news is useful because it exposes both ends of the same problem. Satlyt points outward to remote and intermittent compute. CedarDB points inward to the data layer under AI applications. The operator in the middle has to orchestrate both.

What to do this week

1. Inventory AI artifacts separately: model weights, datasets, vector indexes, transactional databases, checkpoints, caches, and tenant home directories.
2. Define service classes that include CPU, RAM, storage, cache, and GPU type, not only full GPU counts.
3. Review the last 30 days of GPU jobs and identify workloads with low accelerator duty cycle caused by data staging, database waits, or idle notebooks.
4. Create at least one fractional or shared GPU tier for notebooks and bursty inference, where hardware support and isolation requirements allow it.
5. Add storage and database usage to chargeback reports, including GB-months, snapshots, and high IOPS tiers.
6. Test one disconnected or low bandwidth operating procedure for image updates, model synchronization, logs, and metering.

ClastIQ runs this on the operator's own hardware. request a demo

Sources

TechCrunch, The 2026 Startup Battlefield Top 20