4 points par GN⁺ 2026-03-13 | 2 commentaires | Partager sur WhatsApp
  • Résultats d’une évaluation de la capacité du tout nouveau MacBook Neo à gérer des charges de travail de base de données à l’aide des benchmarks ClickBench et TPC-DS SF300
  • Le modèle utilisé pour l’expérience était équipé d’une puce Apple A18 Pro à 6 cœurs, de 8 Go de mémoire et d’un SSD de 512 Go ; les tests ont été réalisés avec DuckDB v1.5.0 et v1.4.4 LTS
  • Sur ClickBench, le MacBook Neo a obtenu de meilleurs résultats à froid que des instances cloud, un avantage attribué à la rapidité d’accès du SSD NVMe local
  • Dans le test TPC-DS SF300, certaines requêtes ont provoqué jusqu’à 80 Go de déversement sur disque, mais toutes les requêtes ont été terminées en 79 minutes, de manière stable
  • Il existe des limites pour les tâches quotidiennes de big data, mais l’essai montre qu’il est tout à fait exploitable comme ordinateur portable client pour DuckDB

Spécifications du MacBook Neo et objectif du test

  • Le MacBook Neo lancé par Apple a été présenté comme un produit destiné aux étudiants et aux écrivains, mais l’équipe DuckDB en a évalué les performances dans la logique du « big data sur ordinateur portable »
    • En Europe, le modèle commercialisé n’inclut pas de chargeur, seuls l’ordinateur portable et un câble USB-C sont fournis
    • Les seules options disponibles sont un SSD de 256 Go ou de 512 Go ; le test a été effectué avec le modèle 512 Go
  • Il embarque 8 Go de mémoire et une puce Apple A18 Pro (6 cœurs)
    • L’iPhone 16 Pro, équipé de la même puce, avait déjà terminé le TPC-H SF100 en moins de 10 minutes lors d’un test précédent

Benchmark ClickBench

  • ClickBench est un benchmark de base de données analytique qui exécute 43 requêtes sur une table unique de 100 millions de lignes
    • Taille des données : 14 Go au format Parquet, 75 Go en CSV
  • DuckDB v1.5.0 a été porté et exécuté sur macOS, avec une limite mémoire fixée à 5 Go afin de réduire la dépendance au swap
  • Éléments de comparaison :
    • MacBook Neo (2P+4E cœurs, 8 Go de RAM)
    • AWS c6a.4xlarge (16 vCPU, 32 Go de RAM)
    • AWS c8g.metal-48xl (192 vCPU, 384 Go de RAM)

Résultats et analyse

  • Résultats à froid :
    • Le MacBook Neo a terminé toutes les requêtes en moins d’une minute, avec une médiane de 0,57 s, soit la meilleure performance
    • Les instances cloud ont été plus lentes en raison de la latence du stockage réseau
  • Résultats à chaud :
    • Le temps d’exécution total du MacBook Neo s’est amélioré d’environ 10 %
    • Le c8g.metal-48xl est globalement le plus rapide, mais le MacBook Neo fait mieux que le c6a.4xlarge en temps médian
    • Le temps d’exécution total reste environ 13 % plus lent que celui du c6a.4xlarge

Benchmark TPC-DS

  • Utilisation de DuckDB v1.4.4 LTS, avec une limite mémoire de 6 Go
  • SF100 :
    • Temps médian par requête de 1,63 s, pour un total de 15,5 minutes
  • SF300 :
    • Temps médian par requête de 6,90 s
    • Déversement sur disque atteignant jusqu’à 80 Go
    • La requête 67 a pris 51 minutes, et l’ensemble des requêtes a été terminé en moins de 79 minutes

Éléments à considérer avant l’achat

  • Pour un traitement continu de big data, les principaux facteurs limitants sont les E/S disque (1,5 Go/s) et les 8 Go de mémoire
    • Un modèle Air ou Pro (3–6 Go/s), ou un ordinateur portable reposant sur un autre OS, sera plus adapté
  • En revanche, si DuckDB s’exécute dans le cloud et que la machine locale sert de client, le MacBook Neo est amplement utile
    • Il peut aussi gérer de façon fiable un traitement local occasionnel des données

Conclusion

  • Malgré son positionnement d’entrée de gamme, le MacBook Neo peut mener à bien de lourdes charges de travail de données avec DuckDB
  • Même face à un environnement cloud, l’avantage du SSD local ressort nettement
  • Il est présenté comme un appareil au minimum de spécifications permettant aux développeurs et analystes de données de concilier portabilité et performances expérimentales

2 commentaires

 
GN⁺ 2026-03-13
Avis de Hacker News
  • Je voulais voir si je pouvais faire du « vrai travail de développement » avec ce petit MacBook Neo
    J’ai créé plusieurs apps iOS sur un MacBook Air M1 et traversé deux acquisitions de startup
    Je pouvais monter sans problème des vidéos de course 4K de 30 à 45 minutes avec FCP, et le Neo offre de meilleures performances que cet Air

    • À l’époque, je développais un backend PHP et un frontend jQuery sur un portable d’occasion avec un clavier norvégien
      Les projets réalisés dessus m’ont permis d’obtenir mon premier poste de développeur, et c’est ce jour-là que j’ai découvert Hacker News pour la première fois
      Au final, ce qui compte, ce n’est pas le matériel, mais la capacité à passer à l’action
    • En vacances, j’ai déjà développé avec un combo Galaxy S22 + adaptateur HDMI + clavier Bluetooth au lieu d’un portable
      Branché à une TV, je faisais du développement Elixir avec neovim et termux, et les tests se terminaient en 5 secondes
      Les builds Rust étaient lents, mais grâce à la portabilité et à l’efficacité énergétique, c’était une expérience plutôt agréable
    • J’utilise encore un Intel MacBook Pro (16GB) de 2019
      Il tient bien même avec des builds Xcode, Docker, Claude Code et Codex lancés en même temps
      En revanche, le bruit du ventilateur est au niveau d’un avion à réaction, donc j’ai commandé un nouveau M5 Max 16" MBP (48GB)
      Comme je change de machine tous les 7 ans, je pense garder celui-ci longtemps aussi
    • J’ai compilé des apps iOS pendant un an sur un M1 Mac Mini (8GB)
      Ça ralentissait un peu pendant les builds, et le changement d’onglet devenait plus lent en revenant sur Firefox, mais c’était tout à fait faisable
      En faisant le même travail sur un Intel MacBook Pro (16GB), c’était bien plus fluide et agréable
      La différence de réactivité de l’OS se ressentait beaucoup
    • Les gens sous-estiment souvent les 8GB de mémoire
      Grâce à la mémoire compressée, on peut en pratique faire tenir 2 à 3 fois plus de données, et avec un SSD NVMe la lecture du swap reste rapide
      En réalité, le vrai manque, c’est plutôt l’absence de rétroéclairage du clavier
  • Quand j’enseigne, je classe les données ainsi — si tout tient dans la mémoire d’une machine, c’est du Small data ; si ça tient sur disque, c’est du Medium data ; au-delà, c’est du Big data
    En modernisant récemment une app Python vieille de 20 ans, j’ai rendu possible le remplacement du backend par polars ou duckDB, et la vitesse a augmenté de 40 à 80 fois
    Ce travail n’a pris que deux jours

    • Aujourd’hui, on peut mettre jusqu’à 64TB de RAM DDR5 dans une seule machine, donc hors cas data lake, presque tout est du Small data
    • Je suis curieux de savoir pourquoi polars a apporté un tel écart de performance
      C’est rapide quand on l’utilise correctement, mais les performances peuvent fortement chuter si on s’y prend mal
    • Un lien classique mais toujours pertinent : Your Data Fits in RAM
      Même si c’est cher, la plupart des problèmes tiennent encore en RAM
    • Grâce au NVMe, l’accès disque est devenu si rapide que la définition de « Medium data » est elle aussi devenue floue
      L’infrastructure Big Data façon années 2000 semble désormais dépassée
  • En lisant le billet de benchmark mobile de DuckDB, j’ai perdu confiance
    Comparer une app Swift et une app CLI, c’était un peu comme comparer des pommes et des bananes

    • Mais cette expérience faisait tourner une app CLI locale sur smartphone
      Ce n’était pas une comparaison entre iPhone et Android, mais avec un système d’article de recherche sur le traitement de requêtes vectorisé
  • C’est aussi une critique des performances de calcul d’AWS

    • AWS utilisait du stockage réseau EBS, donc la latence est bien plus élevée que sur un bus PCIe local
      Cela fait une grande différence, surtout sur des charges à accès aléatoire
    • Malgré tout, AWS n’était-il pas plus rapide que le portable ?
      Le fait que le disque réseau ait été lent rend difficile une critique de l’ensemble d’AWS
      AWS propose aussi des instances avec SSD local
    • Mais le cloud reste excessivement cher
      Mon portable M1 Max surpasse la plupart des instances cloud
      Les prix de la bande passante peuvent différer d’un facteur 10 000, et désormais la majorité des nouvelles générations de développeurs ne connaissent que le cloud SaaS
      J’ai vu cette évolution se produire en temps réel
    • En réalité, l’article disait l’inverse
      « Si vous faites tous les jours du Big Data sur un portable, le Neo n’est pas adapté »
      « En revanche, si vous exécutez DuckDB dans le cloud et utilisez le portable comme client, c’est excellent », c’était l’idée
  • Je suis un écologue sans grands moyens, mais je peux faire tout mon travail sur R et Word avec ce petit ordinateur
    Je suis très satisfait de la qualité de fabrication, remarquable pour le prix

    • Vous travaillez peut-être sur la recherche sur les coquillages ?
      C’est dommage, la plupart des programmes publics de recherche sur les coquillages de notre région ont été arrêtés
    • Mais vous l’avez déjà acheté ? Je croyais qu’on en était encore à la phase de précommande
  • J’adore vraiment DuckDB
    J’ai fait un PoC sur AWS Lambda pour traiter des données stockées compressées en GZ sur S3,
    et j’ai remplacé 400 lignes de code C# par 10 lignes
    C’est un outil open source incroyable

    • À mon avis, c’est l’un des plus beaux cadeaux open source sortis ces dernières années
  • J’aimerais que tous ceux qui disent « qu’est-ce qu’on peut encore faire avec 8GB en 2026 ? » lisent ce genre d’article

  • J’aimerais que plus d’entreprises publient ce type de démonstration de performances sur du matériel grand public
    C’est utile de montrer quel niveau de charge on peut réellement encaisser

  • Pour le benchmark, il aurait fallu utiliser des instances NVMe locales (c8gd.4xlarge)

    • Bonne remarque, j’ai donc refait les tests avec c8gd.4xlarge (950GB NVMe) et c5ad.4xlarge (configuration RAID 0)
      J’y ai aussi comparé les résultats de mon MacBook M1 Max local (64GB, 10 cœurs)
      Au final, le M1 Max reste plus rapide que les instances cloud
      Avec un M5 Pro/Max récent, l’écart serait sans doute encore plus grand
    • Mais le NVMe local d’AWS est un stockage éphémère, donc il faut recharger les données à chaque fois
      Cela dit, pour un benchmark, c’est presque idéal
    • En revanche, en cas de panne de courant à l’échelle d’une région, la garantie de persistance des données reste encore incertaine
      Si l’on veut une durabilité complète, il faut toujours du streaming WAL
  • C’était bien d’avoir immédiatement relevé que les instances cloud utilisaient un disque réseau
    Dans ce cas, je me demande pourquoi les benchmarks n’ont pas été refaits avec des instances à stockage local (c8id.2xlarge, c8id.4xlarge)

 
dkang 2026-03-14

Il y a apparemment eu un commentaire demandant, comme l’identifiant du pauvre écologue est clamlady, si cette personne étudiait les coquillages. (Comme je pensais que « coquillage » était une mauvaise traduction, je suis allé voir l’original par curiosité.)