欢迎来到今天的 Hacker News 每日播报，我们将一同探索从个人化小应用到大型AI模型，再到数据基础设施和奇妙科技的最新动态与深度思考。
Scrappy – Make little apps for you and your friends
今天，我们首先关注一个充满创意和人情味的项目——Scrappy，它旨在帮助你为自己和朋友制作小巧实用的应用程序。在当今软件世界，要么是面向大众的巨型应用，要么是昂贵的企业定制方案，Scrappy 试图填补中间的空白，让软件创作变得更具创意、个人化和表达性，实现“重新分配软件生产资料”的愿景。
Scrappy 的核心是一个基于无限画布的工具，类似于 Figma 或 Miro，但画布上的元素（如按钮、文本框）都是交互式的。用户可以通过属性面板修改它们，并用少量 JavaScript 代码添加行为。整个过程是逐步构建的，通过调整对象和添加代码来完成。
Scrappy 的核心特性
- 始终在线且多人协作： Scrappy 应用（他们称之为 "Scrapps"）天生支持多人使用，状态持久化并实时同步，就像 Google Docs。你甚至可以在朋友使用应用时直接修改它。
- 可视化数据： 应用的数据和计算过程可以在画布上可见，有助于调试和修改。
- 选择性分享与低门槛： 可以通过“框架”功能分享应用的一部分，创建功能受限但仍与主应用关联的版本。分享 Scrapp 只需要一个链接，无需注册账号。
作者将 Scrappy 定位为“小型计算”、“休闲编程”和“家常软件”运动的一部分，旨在赋能终端用户。它借鉴了 HyperCard、Visual Basic 等经典环境，以及 Notion、Figma 等现代工具的协作模式。Scrappy 刻意避免了完全依赖 LLM 生成代码的模式，而是专注于直接操作和用户控制。
社区热议：托管、AI与未来
关于 Scrappy 的讨论非常活跃。许多人对 Scrappy 的托管模式和软件的长期可用性表示关注，认为个人项目可能需要长期运行，而依赖第三方服务存在风险，更倾向于自托管或本地优先的模式。作者回应称，Scrappy 采用了本地优先架构，数据存储在浏览器本地，仅依赖一个轻量级的同步服务器进行协调。
与现有工具的比较是另一个热门话题。许多人将 Scrappy 与 HyperCard、Visual Basic、MS Access 等经典可视化开发工具进行对比，认为 Scrappy 是这些理念在现代 Web 环境下的复兴。同时，也有人提到了 TiddlyWiki、Hyperclay 等其他旨在实现单文件、自修改或易于分享的小型应用创建工具。
AI 生成代码的冲击也被广泛讨论。一些人认为，对于 Scrappy 旨在解决的简单问题，当前的 LLM 已经能够快速生成代码。然而，另一些人反驳说，AI 生成的代码对于非程序员来说难以理解和修改，而 Scrappy 提供的可视化、可直接操作的环境更适合学习和迭代，也更有创造乐趣和协作空间。
此外，关于目标用户和学习曲线，有人质疑 Scrappy 是否真的能触达非程序员用户，认为即使是拖拽加 JavaScript 也可能存在学习门槛。但也有用户赞赏其简洁的 UI/UX，认为它非常适合教学或快速原型开发。移动端支持的重要性也被提及，希望未来能支持在移动设备上编辑。
MiniMax-M1 open-weight, large-scale hybrid-attention reasoning model
MiniMax AI 近日发布了 MiniMax-M1 模型，号称是“世界上第一个开源、大规模混合注意力推理模型”。这款模型总参数量高达 4560 亿，但每次处理时只激活约 459 亿参数，并结合了“闪电注意力”机制。这种混合设计不仅支持长达 100 万 token 的超长上下文，而且在推理时能显著提高计算效率。文章声称，在生成 10 万 token 的长度时，M1 的 FLOPs 消耗仅为 DeepSeek R1 的 25%。
MiniMax-M1 使用大规模强化学习（RL）训练，涵盖了从数学推理到软件工程环境中的工具使用等多种任务。它在软件工程（SWE-bench Verified）、长上下文理解和代理工具使用（TAU-bench）等任务上表现出色，超过了 DeepSeek R1 和 Qwen3-235B 等其他强大的开源模型。MiniMax-M1 已开源，提供了 HuggingFace 模型下载链接，并推荐使用 vLLM 进行生产部署。
社区热议：硬件、背景与未来
关于 MiniMax-M1 的讨论非常活跃。一个最先被关注的话题是运行模型的硬件需求。有人引用 GitHub issue 中的信息，指出运行完整模型可能需要 8 块 H200 141GB 的 GPU，成本高达 25 万美元，这让一些人觉得“开源”的门槛依然很高。但很快有人反驳，认为通过量化（如 Q4 或 Q8）可以在远低于 1 万美元的设备上运行，并讨论了量化对模型性能的影响。
MiniMax 公司的背景和透明度也引发了讨论。有人根据公开信息指出 MiniMax 在上海有母公司，而在新加坡设立了国际运营公司 Nanonoble Pte Ltd，负责中国以外的业务。
在技术细节方面，有人深入研究了技术报告，对“闪电注意力”的构成（87.5% 线性注意力 + 12.5% 全注意力）进行了分析。关于训练成本，有信息指出强化学习部分的训练成本约为 53.47 万美元。
最后，社区对本地运行大型 LLM 的未来普遍持乐观态度。结合 MiniMax-M1 这样的开源模型以及 AMD Strix Halo/Ryzen AI Max 和 Apple Silicon 等新型硬件的发展，许多人认为在未来几年内，在本地廉价地运行强大的 LLM 将成为现实。
Show HN: Lstr – A modern, interactive tree command written in Rust
今天，我们关注一个名为 lstr 的新项目，它是一个用 Rust 编写的现代、交互式目录树查看器。作者旨在提供一个比经典 tree 命令更强大、更具现代感的文件系统浏览体验，并将其定位为快速、极简且交互式的工具。
lstr 的核心要点
- 快速 (Fast): 默认并行扫描目录，充分利用多核硬件性能。
- 极简 (Minimalist): 提供核心功能，界面干净整洁。
- 交互式 (Interactive): 提供可选的终端用户界面 (TUI) 模式，支持键盘驱动的流畅浏览。
lstr 提供了经典模式（类似 tree 命令的文本输出）和交互模式。交互模式下，用户可以通过键盘上下移动选择，按 Enter 键展开/折叠目录或用默认编辑器打开文件，按 Ctrl+s 可以退出并将当前选中的路径打印到标准输出，方便与其他命令结合。此外，lstr 还支持显示文件类型图标、文件权限、文件大小，并集成了 Git 功能，可以直接在树状图中显示文件的 Git 状态。
社区热议：二进制大小与 Rust 生态
关于 lstr 的讨论很快聚焦到了一个常见的 Rust CLI 工具话题：二进制文件大小。有用户注意到初始构建的二进制文件很大（53M），并将其与经典的 tree 命令（几十 KB）进行了对比。作者和其他用户迅速澄清，53M 是调试构建的大小，而发布构建 (cargo build --release) 大约是 4.3M，通过优化编译选项可以进一步减小到 2.2M 到 2.9M 之间。
关于二进制大小的讨论引发了一些更深入的观点：Rust 二进制文件通常包含其运行时和依赖库的代码，导致静态链接后比 C/C++ 同类程序大。一些人认为，考虑到 lstr 提供了交互式 TUI、并行扫描和 Git 集成等高级功能，几兆字节的大小是可以接受的。另一些人则坚持认为，对于一个命令行工具来说，几兆字节仍然是“巨大”的，并将其与软件整体越来越大的趋势联系起来。
此外，有用户提到了 eza 和 broot 等其他用 Rust 编写的现代文件系统工具，暗示了 lstr 在这个领域面临一些竞争。
I counted all of the yurts in Mongolia using machine learning
今天我们关注一篇引人入胜的文章：《我使用机器学习统计了蒙古国所有的蒙古包》。作者 Monroe Clinton 在听完关于蒙古帝国历史的播客后，对现代蒙古社会产生了好奇，特别是卫星地图上乌兰巴托郊区大片大片的蒙古包（在蒙古语中称为 Ger）。由于找不到官方或现有的蒙古包数量统计，他决定自己动手，利用机器学习来完成这项独特的计数任务。
作者选择了 Google Maps 的卫星图像作为数据源，并利用 Label Studio 手动标注了超过 10,000 个蒙古包的边界框，然后选择了 YOLO11 目标检测模型进行训练。面对庞大的蒙古国土面积，他通过分析 OpenStreetMap 数据中人类聚居点的位置，划定了搜索缓冲区，将需要分析的瓦片数量大幅减少。为了提高标注效率，他构建了一个简单的 FastAPI 后端，让 Label Studio 可以调用初步训练的模型进行预标注，再由他人工修正。最终，他使用 Docker 和 Docker Swarm 构建了一个分布式系统，并行处理瓦片下载、模型推理和结果上传。
最终，作者报告共找到了 172,689 个预测置信度高于 40% 的蒙古包。他承认这可能不是一个绝对精确的数字，但提供了一个基于卫星图像和机器学习的估算。文章的后半部分探讨了蒙古包背后的社会文化意义，指出它们不仅是历史游牧生活的遗迹，也是快速城市化背景下，许多从农村迁往城市的牧民在“蒙古包区”的居所。
社区热议：文化、技术与估算
关于这篇文章的讨论非常热烈，视角多样。许多人深化了对蒙古包文化意义的理解。有去过蒙古的网友分享观察到，即使住在永久性房屋里的人家，院子里也常有一个蒙古包，这不仅仅是额外的居住空间，更是文化符号、待客场所，是与游牧传统保持联系的方式。这与作者将蒙古包区主要视为政策失败的观点形成了对比，一些人认为，对于部分人来说，住在蒙古包可能是文化或理性选择。同时，也有人指出，城市蒙古包区普遍缺乏基础设施（水、电、排污），冬季燃煤取暖导致严重空气污染，这些恶劣的生活条件确实是政策失败的体现。
技术实现细节和结果的准确性也引发了讨论。有人建议作者可以利用 OpenStreetMap 中已有的近 9 万个标注好的蒙古包数据作为训练或验证集，但也有人解释了使用第三方地图数据的许可限制、数据对齐问题以及蒙古包本身的移动性等因素。关于最终计数，一些人认为将其称为“计数”不够严谨，更准确的说法应该是“估算”，并对模型精度、40% 的置信度阈值选择以及缺乏误差分析和置信区间表示担忧。
3D-printed device splits white noise into an acoustic rainbow without power
今天我们来聊一篇在 Hacker News 上引起热议的文章：《无需电力，3D 打印设备将白噪声分解成“声学彩虹”》。这篇文章介绍了一种名为“声学彩虹发射器”（Acoustic Rainbow Emitter, ARE）的新型 3D 打印设备。它的核心功能是接收来自点声源的宽带白噪声信号，然后将其散射开，使得不同频率的声音朝向不同的方向传播。这就像光学棱镜将白光分解成可见光谱的彩虹一样，这个设备则在声学领域实现了类似的效果。
核心技术与应用前景
这项设备是一种完全被动的结构，仅依靠其精心设计的物理形状来操控声波，无需任何电力或主动元件。研究人员的灵感来源于自然界，比如人类、蝙蝠和海豚耳朵的复杂结构。为了实现这种复杂的声波操控，研究团队采用了计算形态发生学（computational morphogenesis）的方法，结合拓扑优化、波基建模和 3D 打印技术。除了 ARE，研究人员还设计了一个“lambda 分裂器”，可以将混合频率的声音引导到不同的方向。
关于应用前景，社区成员们展开了热烈的讨论和头脑风暴。有人提出将其用于制造新型乐器，通过旋转设备来改变发出的音调。在更实际的层面，有人认为这种技术可以用于建筑声学设计，例如被动地引导或分散恼人的噪音。还有人看到了它在传感和定位方面的潜力，比如帮助机器人或视力障碍者通过声音来感知环境和确定位置。
同时，讨论中也出现了一些与此相关的技术和现象的讨论，比如声学衍射光栅、亥姆霍兹共振器，以及扬声器中使用的声学超材料。尽管有人指出文章中展示的设备工作频率范围相对有限，但普遍认为这只是一个概念验证的研究原型，证明了这种被动声波控制方法的可行性，未来的设备有望覆盖更宽的频率范围。
Locally hosting an internet-connected server
今天我们要聊的话题是：如何在本地托管一个连接到互联网的服务器。这听起来可能像是互联网早期就解决的问题，但在2025年，这依然充满了挑战。
这篇文章的核心在于探讨如何在家庭或本地网络环境下，克服现代互联网服务提供商（ISP）的限制，成功地将一个或多个服务器暴露给公共互联网。作者面临的主要问题是住宅宽带通常没有静态的公共 IPv4 地址，或者即使有，也只有一个，并且 IPv6 的支持要么缺失，要么不稳定。这使得在本地托管多个需要独立访问的服务变得困难。
解决方案与社区讨论
虽然我们无法直接访问文章全文，但从讨论可以高度推断，作者采取了一种利用廉价的虚拟私有服务器（VPS）作为跳板的方案。具体来说，作者可能在本地服务器和远程VPS之间建立了一个安全的隧道（很可能是 Wireguard），然后通过在VPS上进行网络地址转换（NAT）或路由配置，将VPS的公共IP地址或其上的特定端口流量转发回本地网络中的不同服务器。
这种方法的核心优势在于：绕过动态IP和CGNAT（运营商级NAT），VPS拥有稳定的公共IP，所有外部流量都导向这里；通过在VPS上配置路由或端口转发，可以将不同的公共IP地址或同一IP的不同端口映射到本地网络中的不同机器或服务上，解决了单IP下难以托管多个相同类型服务的问题；外部用户连接的是VPS的公共IP，无需了解本地网络的复杂性。
关于文章提出的问题和解决方案，社区展开了热烈讨论。许多人对作者的遭遇深表同情，并指出这是许多 ISP 的普遍问题。尽管 IPv6 早在多年前就被视为解决 IPv4 地址耗尽和静态 IP 需求的方案，但其在住宅用户中的普及和稳定性依然堪忧。CGNAT 被多次提及，它不仅阻止了外部连接到本地网络，还对用户作为客户端造成困扰，因为多个用户共享同一个公共 IP，可能导致 IP 被网站或 CDN 标记。
讨论中也提到了多种替代方案，例如动态 DNS（无法解决 CGNAT 问题）、端口转发/反向代理（增加了客户端复杂性），以及更简便的托管隧道服务如 Tailscale 和 Cloudflare Tunnels。但也有人指出，使用托管服务意味着将流量置于其控制之下，而手动 VPS 方案提供了更大的自主权。一些资深用户甚至分享了他们通过购买 IPv4 地址段并使用 BGP 路由的经验，实现了完全的控制，但这门槛和成本较高。
Show HN: Workout.cool – Open-source fitness coaching platform
今天我们要聊的是一个名为 Workout.cool 的新项目，它是一个现代开源健身指导平台。项目的发起者 surgomat 讲述了一个有意思的起源故事：他曾是另一个流行开源健身项目 workout.lol 的主要贡献者，但该项目因视频授权问题被出售并最终停滞。在尝试联系无果后，surgomat 决定从零开始，以同样的开源精神，但采用更好的架构和解决方案，重新打造了这个平台。他强调这不是为了盈利，而是为了社区。
平台亮点与社区反馈
Workout.cool 的核心目标是提供一个完全开源的平台，帮助用户创建健身计划、追踪训练进度，并提供一个包含详细说明和视频演示的全面练习数据库。平台内置了超过 1200 个练习，每个练习都包含视频、属性和多语言翻译。项目基于 Next.js App Router、TypeScript、Prisma、PostgreSQL 等现代技术构建，并提供了使用 Docker 或手动方式进行本地安装和自托管的指南。
关于 Workout.cool 的发布，许多人对 surgomat 决定“拯救”并重建项目的行为表示赞赏，认为这体现了真正的开源精神。令人惊喜的是，原 workout.lol 的作者 Vincenius 也出现在讨论中，表达了看到项目被重新维护的喜悦，并与 surgomat 进行了友好的互动。
项目刚发布就遭遇了流量高峰，导致网站出现“Error loading exercises”的错误。surgomat 积极回应，解释是后端限流和数据库负载过高所致，并表示正在紧急修复。
关于训练计划生成逻辑，这是讨论最集中的一个点。一些有经验的健身者认为，当前平台根据选择的肌肉和器械随机推荐练习的方式过于简单，生成的训练计划不符合科学的训练原则。他们认为这种方式对初学者可能没有帮助，甚至有潜在的受伤风险。他们建议项目应该更侧重于让用户创建和追踪自己的计划，或者引入社区分享的成熟计划模板。surgomat 虚心接受了这些反馈，承认当前的生成逻辑确实基础，并表示未来会改进。
此外，一些健身新手表示，项目当前的流程对他们来说不太友好，因为他们可能不了解具体的肌肉名称，更习惯于按目标或按动作类型来思考。他们建议增加更适合初学者的入门方式和预设选项。
Introduction to the A* Algorithm (2014)
今天我们要聊的是一篇来自 Red Blob Games 的经典文章：《A* 算法简介 (2014)》。这篇文章深入浅出地解释了 A* 寻路算法，以及它与几种相关图搜索算法的关系。
文章首先介绍了图搜索算法的核心目标：在表示为图的地图上找到最短路径。它引出了三种主要的算法：广度优先搜索（BFS）、Dijkstra 算法和 A* 算法。BFS 像洪水一样向所有方向均匀探索，找到的是步数最少的路径；Dijkstra 算法考虑了移动成本，找到的是总成本最低的路径；而 A* 算法则更聪明，它会优先探索那些更接近目标的区域。
算法原理与社区洞察
文章详细阐述了这些算法的工作原理，通过动画和 Python 伪代码，逐步展示了 BFS 如何使用队列来探索，以及如何通过记录“came_from”来重建路径。核心部分是 Dijkstra 算法和 A* 算法的讲解。Dijkstra 算法通过引入“cost_so_far”变量和使用优先队列来处理不同的移动成本。A* 算法在此基础上更进一步，它在优先队列的优先级计算中加入了“启发式函数”（heuristic），这个函数估计了从当前节点到目标的距离。A* 的优先级是 cost_so_far + heuristic。文章通过对比动画清晰地展示了 BFS、Dijkstra 和 A* 在不同地图上的探索模式。
关于算法本身，许多人认为 BFS、Dijkstra 和 A* 本质上是同一种算法框架，区别在于它们在优先队列中用来排序节点的“优先级”计算方式不同。BFS 可以看作是优先级等于发现顺序；Dijkstra 的优先级是 cost_so_far；而 A* 的优先级是 cost_so_far + heuristic。这种观点提供了一个统一的视角来理解这些算法。
另一个有趣的讨论点是 A* 算法在游戏或其他应用中的“真实性”与“性能”权衡。有人认为 A* 是一种“性能优化”，并不像真实世界的实体那样思考和行动。反对者则指出，A* 是一个数学上严谨、可证明最优（在可接受启发式下）的算法，它不是为了模拟真实行为，而是为了高效找到最优路径。在游戏开发中，性能和玩家体验往往比完美的物理模拟更重要。
Terpstra Keyboard
本周在 Hacker News 上，一个指向 Terpstra Keyboard WebApp 的链接引发了开发者和音乐爱好者们的热烈讨论。这款应用是 Siemen Terpstra 在上世纪 80 年代设计的 Terpstra 键盘的网页实现，由 James Fenn 开发并有多位贡献者参与，目前是遵循 GPL-3.0 许可的开源项目。
文章本身简明扼要地介绍了这个 WebApp，并提供了访问链接、设计者和开发者的信息，以及项目的 GitHub 仓库。它的核心在于提供一个非传统的键盘布局，允许用户探索标准 12 平均律之外的音律系统，即所谓的“微音音乐”（microtonal music）。应用界面提供了丰富的定制选项，包括调整音高基准、布局方式、按键视觉样式，以及最重要的——加载自定义音阶文件（支持 Scala 格式）。
社区热议：微音音乐与硬件实现
关于 Terpstra Keyboard WebApp 的讨论迅速围绕几个主要话题展开。首先，许多人对微音音乐本身表现出浓厚兴趣，并积极推荐入门资源和艺术家，认为它能带来全新的音乐色彩和情感。
其次，讨论深入到了替代键盘布局和硬件实现。除了 Terpstra 键盘，Jankó 键盘和同构键盘（Isomorphic keyboard）也被提及。这引出了关于物理键盘实现的讨论，有人表达了使用磁性霍尔效应开关构建硬件 MIDI 键盘的愿望，并指出现有物理微音/同构键盘往往非常昂贵。有用户分享了自己使用 Wooting 键盘配合自定义软件实现 MIDI 输出的经验。
再者，针对 Terpstra WebApp 本身，用户提供了使用反馈和技术分析。许多人赞扬了应用的响应速度，尤其是在触摸屏上。有分析指出，其响应性得益于 Web Audio API、预加载音频样本并通过调整播放速率来生成不同音高，以及使用了简洁的 vanilla JavaScript。不过，也有用户报告了在某些浏览器/操作系统组合下存在音符之间的轻微“咔嗒”声，以及网站访问问题。
最后，讨论中还出现了一些有趣的“跑题”，例如关于“Terpstra”这个姓氏的来源，以及关于设计用于脚部演奏的键盘，以实现“一人乐队”的效果。
Timescale Is Now TigerData
今天我们要聊的是数据库领域的一个重要动态：知名的时序数据库公司 Timescale 正式更名为 TigerData。
这篇来自 TigerData 官方博客的文章，标题是《Speed Without Sacrifice: Building the Modern PostgreSQL for the Analytical and Agentic Era》，直译过来就是“速度不妥协：为分析和智能体时代构建现代 PostgreSQL”。文章由联合创始人 Ajay Kulkarni 和 Mike Freedman 撰写，核心信息非常明确：Timescale 不再仅仅是时序数据库公司了，他们已经发展成为一个更广泛的、基于 PostgreSQL 的数据平台，服务于各种现代工作负载，因此更名以反映这一变化。
文章回顾了 Timescale 八年前创立时的背景，当时 NoSQL 数据库风头正劲，而 PostgreSQL 被认为是“老派无聊”的。Timescale 逆势而行，选择在 PostgreSQL 上构建时序数据库。快进到今天，文章作者宣称“PostgreSQL 已经赢了”，而 MongoDB、Cassandra、InfluxDB 等 NoSQL 数据库则被视为“技术死胡同”。他们认为，现代应用需要快速的数据库，尤其是在“智能体时代”（Agentic Era），智能体需要快速的向量搜索、快速的数据环境分支等能力。
Timescale 已经从一个时序数据库发展成为一个拥有 2000 家客户、中八位数 ARR（年经常性收入）、年增长率超过 100%、融资 1.8 亿美元的蓬勃发展的业务。他们服务于 Mistral、HuggingFace、Nvidia、Toyota、Tesla、NASA 等知名公司，这些公司正在构建实时分析产品和大规模 AI 工作负载。文章强调，他们云产品上的大多数工作负载已经不是纯粹的时序数据了，很多公司直接将整个应用运行在他们的平台上。
因此，更名为 TigerData 是为了反映他们已经成为“最快的 PostgreSQL”，提供“速度不妥协”的能力。公司名称改为 TigerData，云服务称为 Tiger Cloud，但开源的时序扩展 TimescaleDB 和向量扩展 pgvectorscale 将保留原名。
社区热议：更名、营销与产品
关于这次更名和公告，社区的反应是相当多元的。首先，关于更名本身，不少人对 Timescale 放弃一个已经建立起来的、有辨识度的品牌表示不解，认为这是一个“糟糕的选择”。他们指出，数据库领域已经存在多个带有“Tiger”或类似发音的名称，例如 TigerBeetle、TigerGraph、WiredTiger (MongoDB 的存储引擎) 甚至 Tigris Data。这种命名上的冲突和混淆是讨论最集中的担忧之一。
其次，关于文章中大胆的市场营销语言。文章中“NoSQL 数据库被视为技术死胡同”、“PostgreSQL 已经赢了”等论断引发了强烈反弹。许多人认为这种说法过于傲慢和脱离实际。他们指出，MongoDB、Cassandra 等 NoSQL 数据库在特定场景下依然非常活跃和适用，并且许多专业化数据库正在挑战传统的 SQL 数据库。
第三，关于 Timescale/TigerData 的产品和用户体验。有长期用户表示，TimescaleDB 在处理大量工业机器人数据方面表现出色，是他们项目的可靠组成部分。他们特别提到了其在时序数据处理上的优势，但也提到了一些不足，例如感觉托管服务像是“不受待见的继子”。另一位用户则分享了不太积极的经验，认为要充分利用 TimescaleDB 需要一个全职的 DBA 专家。Timescale 的联合创始人 Ajay Kulkarni 也亲自在讨论中回应了这些反馈。
最后，讨论中自然提到了其他时序数据库或分析型数据库。InfluxDB 被多次提及，有用户批评其版本迭代带来的迁移痛苦。ClickHouse 也被拿来比较，但 Timescale 方面则提出了他们自己的 RTABench 基准测试，认为更能代表实时分析工作负载。