Analytics that fits in memory: up to 1.5 TB

Distributed systems pay for every node boundary with network shuffles, coordination and operational work. With up to 1.5 TB of RAM and 192 cores in one server, many analytical workloads that would need a cluster of smaller machines fit on one or two large nodes.

• ClickHouse scales vertically well: give it all the cores and enough RAM for hot parts and its caches.
• DuckDB runs in-process on a single node and benefits directly from large RAM and fast NVMe.
• Spark in local mode on one big node avoids network shuffles entirely; in a small cluster, run several executors per host.

On the dual-socket Max 192, memory is split by default into two NUMA nodes, one per CPU. Memory-intensive engines run best when each process stays on one socket: pin instances with numactl, run one instance per socket, or enable the engine's NUMA awareness where it exists. The single-socket Max 96, with 96 cores and 1,152 GB of RAM, avoids the question entirely.

Max servers have four 7.68 TB NVMe Gen5 drives (30.72 TB raw), and the Pro 64 has four 3.84 TB drives. Choose the layout by where redundancy lives:

• Replicated at the data layer (ClickHouse ReplicatedMergeTree, Kafka replication, OpenSearch replicas): use the drives individually in a JBOD storage policy, or striped, and let replicas on other servers cover drive failures.
• Single node without replicas: RAID 10 for about 15 TB usable on a Max server, with backups elsewhere.

Tier your data. Keep recent partitions on NVMe and move older ones to cheaper capacity: ClickHouse storage policies can move parts to an S3-compatible store, which you can run yourself, for example with Ceph RGW or SeaweedFS on a Storage 264 (264 TB raw) in Ashburn, Los Angeles, Amsterdam or Frankfurt.

Compression changes the math: columnar engines often store data several times smaller than its raw size, so estimate disk needs from a sample of your own data rather than from source sizes.

When one node isn't enough, keep cluster traffic on the private VLAN: servers in the same location share it for free, and internal traffic is not billed. Practical starting points per engine:

• ClickHouse: shard across Pro 64 or Max nodes with two replicas per shard, and run ClickHouse Keeper on three nodes for coordination. Keeper needs little hardware, so small servers such as the Core 16 are enough.
• Spark: size executors at about 4 to 8 cores each with memory to match, and put shuffle and spill directories on NVMe.
• Kafka: at least three brokers with a replication factor of 3, logs on NVMe.
• OpenSearch or Elasticsearch: keep each JVM heap below about 30 GB so compressed object pointers stay enabled, leave at least half of RAM to the file-system cache, and run several nodes per host on large servers.

The Max 192 has 2 × 100 Gbps ports for shuffle-heavy clusters, and the Pro 64 and Max 96 have 2 × 25 Gbps. Analytics is often bound by data movement, so measure throughput between nodes early.