数据库是业务架构的核心，是不言自明的共识。但如果我们更进一步，将数据库作为业务架构本身，将业务逻辑甚至 HTTP Server 都放入数据库中，又会有怎么样的火花？
在1月4日举办的第七届PG生态大会上，我邀请尤里来中国，进行了题为《数据库驱动未来》的主题分享。 他抛出了这个观点 —— 数据库就是业务架构。简单说，他的开源 PostgreSQL 项目 —— Omnigres ，尝试把所有应用的业务逻辑，甚至是 HTTP 服务器都放入 PostgreSQL 数据库中。
如果你觉得这听上去有点不靠谱，先别急着下结论 —— 我也曾亲眼目睹过这样的成功实践，所以今天就来和大家探讨下这个有趣的话题。
数据库是架构的核心
“If you show me your software architecture, I learn nothing about your business. But if you show me your data model, I can guess exactly what your business is.”。
数据库祖师爷迈克·石破天（Michael Stonebraker）有句名言：“如果你给我看软件架构，我对你的业务一无所知；但如果你给我看数据模型，我就能精准知道你的业务是干嘛的”
无独有偶，微软的 CEO 纳德拉也公开表示：我们今天所称的软件，其实只是数据库上的一个华丽界面。他将其简化为一个叫“CRUD”的概念：创建（Create）、读取（Read）、更新（Update）和删除（Destroy）。
也就是说，你喜欢的那些应用程序，不过是包装精美的数据库操作界面而已。BTW， Nadella 还提出 SaaS is Dead：因为以后 Agent 可以直接绕过中间商，代替前后端去读写数据库了。
即使在 GenAI 爆火的当下，绝大多数信息系统的整个 IT 技术栈依然是以数据库为核心设计的。无论业务架构怎么折腾，底层的东西永远是万变不离其宗。所谓的分库分表，几地几中心，异地多活这些架构花活，说到底也就是数据库的不同使用方式罢了。
数据库是业务架构的核心，是不言自明的共识。但如果我们更进一步，将数据库作为业务架构本身，又会如何？
什么，还能这么玩
在 PG 生态大会上，尤里展示了一个思路：把所有业务逻辑，甚至是Web服务器都塞进 PostgreSQL 里。比如可以通过写存储过程，把原本后端的一部分功能直接放到数据库里执行。为此，他还基于 PG 扩展做了很多“标准库”，从 HTTP、vfs、os 到 Python 模块，都可以内嵌在 PostgreSQL 中。
让我们来看一个有趣的例子，在 PostgreSQL 中执行以下 SQL，将会启动一个 Web 服务器，将 /pg/bin/
（或者其他任何目录）作为一个 Web 服务器的根目录对外提供服务。
是的，夭寿啊，PostgreSQL 数据库竟然拉起来了一个 HTTP 服务器，默认跑在 8080 端口！你可以把它当成 Nginx 用！
但更重要的是，你还可以将任意的 PostgreSQL 函数（支持 20 多种存储过程语言）挂载到 HTTP 端点上，实现你想要的任何东西。像这样的 Omni 扩展总共有 33 款，当然也不要忘了 PG 生态里还有接近 400 个开箱即用的扩展插件可以提供各种功能
这一套扩展全家桶，提供了在 PostgreSQL 中进行 Web 开发的能力！
在数据库中跑Web服务器是馊主意吗？
PostgREST 和 Postgraphile 这样的工具，可以将设计良好的 PostgreSQL Schema 直接转化为开箱即用的 RestAPI， 而类似 Omnigres 这样的工具干脆百尺竿头更进一步，直接让 HTTP 服务器运行在了 PG 数据库内部！
目前来说，这种实践绝对算不上主流。站在一个 DBA 的角度来讲，我肯定认为这是一个给 DBA 找麻烦的馊主意。但站在一个开发者，特别是前端开发者的角度来说，我认为这个主意还是很有意思，值得探索的！因为确实很省事 —— 前端一套 Next.js 一把梭，后端一个数据库全部搞定了，架构简单无比。
早先在探探在使用 PostgreSQL 时，几乎所有的业务逻辑（甚至推荐算法）都在 PostgreSQL 里实现，后端只负责很轻的一层封装 只不过，这种做法对开发者、DBA 的综合技能要求较高，毕竟写存储过程、维护复杂的数据库逻辑不是一件轻松活儿。而且那个时候，数据库通常也是整个架构中的性能瓶颈，哪有余量给这些花活。
但现在随着两个关键要素的变化（AI 的出现与硬件性能的严重过剩），利弊权衡发生了改变。GPT 显然已经达到了能够熟练编写存储过程的中高级开发者的水准，而遵循摩尔定律发展的硬件直接把单机性能推到了一个匪夷所思的地步。
数据库中跑Web服务器的利弊
在数据库中跑Web Server这种模式有一些好处：
•你的业务逻辑，业务模型，业务数据放在一个地方，用统一的方式来管理。•你的业务代码就是一个放着 Python JS Java 等存储过程的目录，更新发布，CI/CD 都非常简单。如果负载高要降级，把非关键的存储过程刷新或在数据库里设置标记就实现了。•存储过程避免了应用后端与数据库的多次网络RT，通常有更好的延迟表现（总吞吐量会下降，但以当下的硬件水平与性能余量，Who cares！）•你所需要的只有一个 PostgreSQL 数据库，后端融入到数据库里，运维管理极为便利，方便进行单元化部署与敏捷交付。
这种模式的主要弊病有两个：
1.互联网时代，数据库是瓶颈，难以伸缩，大家希望通过让应用承担更多，数据库退后的方式解决 scale 的问题。2.对开发者水平的要求太高了，用好数据库对开发者本身已经是一件很有挑战的事情，而写存储过程的技能在年轻一代开发者中几乎已经失传了，维护管理更是对 DBA 提出了极高的要求。
但随着时代发展，这两个主要问题得到了解决：硬件的发展让数据库的性能重新出现 巨大 的富余。AI 的出现让开发者的水平（AI加持下）得到了突飞猛进的发展。
前者让数据库性能余量重新回到了一个可以在大多数场景下容纳业务逻辑的地步，后者解决了开发者不会写存储过程的问题。因此在当下，数据库即架构（DBaaA）成为了一种非常值得探索的实践。
数据库即架构理念有一个非常成功的案例 —— Supabase —— 可能有 80% YC 创业公司都在使用它。Supabase 号称自己是一个 Backend as a Service，将 PostgreSQL，对象存储，以及 EdgeFunction 封装成为一整个运行时，然后将后端与传统意义上的数据库整体打包成为一个 “新的数据库”。
但 Supabase 本身仍然是一系列容器组件缝合拼接起来的，如果这种架构走到极致，大概会变成 Omnigres 的样子 —— 一个运行着 HTTP 服务器的 PostgreSQL，Nothing Else。
这也许意味着软件架构的钟摆重新回归简单 —— 绕开花里胡哨的中间件，前端直接访问数据库，甚至连传统移动/Web前端也许最终也会被 LLM Agent 与其他 Interface 替代。最后直接由 Agent 代理访问数据库。
那么要不要试试呢？
顺便一提，我们已经与 Omnigres 达成了合作。昨天在 Omnigres 创始人 Yurii 的帮助下，我为 Omnigres 构建了主流 Linux 上的 RPM/DEB 包，包含了了以下 33 个扩展插件，开箱即用。（https://ext.pigsty.io/#/omni）
Omnigres 提供的 33 个 PG 扩展插件现在可以在 Pigsty 中开箱即用，而 Omnigres 提供的容器镜像中也包括了 Pigsty 的 300+ 扩展，可谓开源生态互惠共赢之典范。
如果你想试试在数据库里写应用，一套 PG 打天下的刺激玩法，确实可以试试这个！
References
[1]
数据库驱动未来: https://gamma.app/docs/The-Database-Drives-the-Future-41vma58e3502p70?mode=doc
