proomt

Search

Search posts, papers, and topics

All posts

PlanetScaleAhmed Darwich6 min readintermediate

When to choose x86-64 vs aarch64

Summary

When provisioning PlanetScale Postgres clusters you must pick either x86‑64 or aarch64, because the two architectures differ in core counting, clock speed, SIMD width, and on‑disk file compatibility. ARM gives more cores per vCPU and lower power, which helps many small queries, while x86‑64 offers higher single‑core performance and wider vector instructions, which helps heavy queries and certain…

  • ARM (aarch64) instances use whole cores per vCPU (no hyperthreading), giving more cores for the same vCPU count, which benefits workloads with many concurrent small queries.
  • x86‑64 instances use hyperthreading, so a vCPU may share a core; they also have higher single‑core clock speeds, making them better for single heavy, CPU‑bound queries.
  • Vector instruction width differs: x86 supports 256‑bit AVX2 and optional 512‑bit AVX‑512, while current Graviton ARM chips only have 128‑bit vectors, giving x86 an advantage for extensions that rely on wide SIMD (e.g.,…
  • Postgres on‑disk files are not portable across architectures; you cannot replica‑promote across ARM ↔ x86, so choose architecture up‑front.

DBAs and engineers deploying Postgres workloads in the cloud should care, because the choice directly impacts query latency, throughput, and migration flexibility.

6/10

Related reading

  1. A practical guide to cost optimization with Lakebase Postgres

    Lakebase’s separated storage‑compute architecture lets you cut database costs by syncing only the active data, picking the right sync mode, and right‑sizing compute so the hot working set fits in cache. Follow the blog’s concrete steps—materialized‑view subsets, snapshot vs triggered vs continuous sync, autoscale bounds, and connection‑pooling—to keep spend predictable without sacrificing perform…

    Databricksdatabricks.com12 min
  2. Postgres on NVMe: performance and the convergence of transactions and analytics

    Local NVMe storage cuts Postgres I/O latency from ms to µs, yielding ~9× higher TPS and 10× lower transaction latency on a 482 GiB pgbench workload. The gain comes from reduced IO wait, not more CPU work. To retain durability, combine NVMe with quorum synchronous replication and continuous WAL archiving (WAL‑G). For analytics, offload scans to ClickHouse via WAL‑based CDC (pg_clickhouse or the ne…

    ClickHouseclickhouse.com8 min
  3. Introducing TIN: full-text search for Postgres

    PlanetScale’s TIN is a new PostgreSQL extension that implements a full‑text search index supporting Boolean, phrase, span, fuzzy, wildcard, regex, case/accent folding, COUNT(*) and BM25 top‑k queries. In a suite of benchmarks on an i7i.8xlarge EC2 instance (8 vCPU, 32 GB RAM), TIN built in 8 min 10 s (50.7 GB index) and outperformed ParadeDB, pg_textsearch and the built‑in GIN index by large marg…

    PlanetScaleplanetscale.com15 minHN20175
  4. Blocking cutovers to save replication slots

    PlanetScale’s Postgres operator blocks cutovers that would leave logical replication slots out‑of‑sync. By requiring `failover=true` on slots and turning on `hot_standby_feedback` and `sync_replication_slots`, the operator ensures slots survive a primary promotion, preventing downstream CDC consumers from losing data.

    PlanetScaleplanetscale.com5 min
  5. PostgresCompare 2.2.0 Released

    PostgresCompare 2.2.0 is a major rewrite (Electron → Tauri) that adds pipelines, quick compare, data‑change scripting, an MCP server for AI‑driven migrations, parallel connections, and a CLI for schema export. UI is restyled, multilingual, and self‑updating. Supports PostgreSQL 9.2‑18 on Windows, macOS, Linux.

    PostgreSQLpostgresql.org3 minrelease