3月的时候收到 PlanetScale 的短信说他们家的免费数据库会在今年4月8号开始收费，互联网上突然冒出了一大批“数据库难民”，四处寻觅免费的替代品。很多人都推荐了 Neon，但我一想到迁移数据库这种非常无趣的运维工作就毫无做的欲望，直到今天数据库被停用了之后才开始搬家之旅。

这件事情，以及关于 “serverless” 的各种新闻，让我对于这个带不少炒作性质的概念有了一些新的想法：

从用户的角度

去年我第一次知道 Vercel 令人匪夷所思的云部署福利后欣喜若狂，也看到网上很多人和我一样对 Vercel, Cloudflare 这些公司感恩戴德，尊称为赛博菩萨。而当人们一开始期待于 Vercel 的kv数据库集成时，定价的公布让用户直接望而却步，转向了 Supabase 和 Planetscale “新一代” 业界良心。可是不到一年过去了，曾经的良心也在经济压力面前倒下了，而新扶持的这位又能撑多久呢？

无服务器这个概念天生就存在陷阱，因为它显然是有服务器的，而真正无服务器的只是用户。过去的 aws，阿里云这种infra层面的云服务，对于整个云平台的可用性与稳定性是有着极高要求的，而稳定性也不只是系统层面的稳定，也包含了持续定价上的一致性。在这种稳定性的加持下，购买者是可以真真切切的感受到自己是有这个服务器的。而现在的无服务器，就像是一种商人的施舍，说不准哪天就收回了。

从商业决策上来说，这种带有一定背刺意味的行为无可厚非，但是无疑会让用户对于这一类公司都有一种不安全感。并且，它们所精心营造的极佳 DX 体验，从比较“阴暗”的角度来看也是一种让人习惯后难以舍弃的糖衣炮弹。

我上面的观点不是对于 Vercel 这些公司的质疑，毕竟大家都是白嫖，心里面显然只有感恩。但是公司背后的商业性不可忽视，尤其是这种几乎全方面黑盒的运营模式。

从商业的角度

商业价值是无法回避的问题，而我一方面作为常年白嫖的用户，另一方面现在也在一家AIGC公司里面做类似的服务开发，对于定价问题时常有些忧虑。

作为广大普通用户，最核心的观念就是：不选对的，只选最便宜的。

这么多年来，我们已经见过了数个本来如日中天的新起之秀，因为定价问题导致用户纷纷离去。Planetscale 就是典型的一例，曾经是行业标杆，如今似乎成为了背信弃义的“无良公司”，令人唏嘘。而反观去年的 Midjournay 和 ChatGPT，尤其是后者离谱的 GPT-4 定价和出尔反尔的宣传加上时不时的网络崩溃，简直就是软件界的灾难。但偏偏这20刀的定价可以屹立不倒，这其中的核心是不可替代性：只有他能被选。

但是去年也传出了 GitHub Copilot 亏损的消息，让这种商业定价的规律更加难以捉摸：即便用户愿意购买，是否盈利依然是一个疑问。

所以从多方面来看，我对于 Vercel 都有着十足的担忧，因为它几乎把所有可能的坑都踩了一边：

1. 以免费服务吸引用户
2. 重infra的运营模式
3. 可替代性。既有同风格的 netify 和 Cloudflare Page，也可以直接购买服务器的正常部署。

Vercel 口碑很好的一点是出色的 DX，但一个很遗憾的事实是，作为以B端为核心盈利模式的产品，DX 根本不值钱。aws等一众不是人用的导航界面，似乎就是在嘲笑这种锦上添花的努力。

因此，我认为当我们选择一个服务时，即便它有再多的精美包装，两个核心问题都是无法回避的：

1. 公司的定价逻辑。这决定了公司靠什么盈利，从 Vercel 计费部分的高额收费，可以看出来他们很想赚钱，或者说只能靠这种高额收费的方式赚钱。
2. 公司的盈利能力。这决定了公司能不能持续提供免费服务，以及会不会突然背刺。强如 Google 也是砍产品风驰电掣，其它公司如何运营更是未知。

从技术的角度

前几年我对新技术有一种狂热的痴迷，但现在静下来想，这个“新”里面有好几种不同的成分：

1. 新且好。GPT 算是一例，Astro 这种框架也可以算。我觉得作为技术爱好者，显然不能固步自封。但是选择技术的核心在于它“好”而不是它“新”，如果说它解决了以前从没有人解决的问题那么自然就是又新又好。
2. 好，但是不新。某种意义上来说，就是旧瓶装新酒，底层逻辑已经延续了很多年了，但是因为某些新的包装，让它看起来焕然一新。而这层包装，在当今往往就是“黑盒换便携性”。Next.js 在新手刚上手时会非常好用，但是随着使用深度的增加，一方面会被迫学习很多纯 hardcode 的 magic，另一方面又对于黑盒有一种观摩金字塔般的困惑。这种“好”，我认为就是 false positive，让人只能理解器的层面而不是道，同时习惯后带来的依赖性让新手开发者可能进退两难。
3. 新，但不好。这个程度可能是渐进的，比如 Zed，现在看起来不具备什么实用性但是说不定几年之后就独当一面了。

关于上面的第二点，也说明真正核心的“基础知识”的重要性。比如这次的服务器迁移，用 prisma orm做了一层工程上的封装确实就方便了很多。

最后写一下步骤吧，没想到前面扯了这么多废话233。

1. 安装 pgloader 用于迁移数据库。这里我用 Ubuntu 22.04 报错了，可以自己从头 build 后运行。
2. 更新 prisma 配置。用 drizzle 也差不多。然后 push 一下。

datasource db {
  provider     = "postgresql"
  url          = env("DATABASE_URL")
  relationMode = "prisma"
}

3. 按照文档随便配一下参数。注意 127.0.0.1:3306 是需要靠本地 pscale cli 起一个服务的。

pgloader --with "quote identifiers" --with "data only" mysql://username:[email protected]:3306/database_name "postgres://alex:endpoint=ep-cool-darkness-123456;[email protected]/dbname?sslmode=require"

最后提一下，用下划线命名确实是好文明，数据库的大小写坑虽然说可以解决，但总还是有点麻烦。下划线轻松而省力，何乐而不为呢。