Ask HN: 有人在这里自建数据库并需要高级功能吗?

1作者: SirusCodes7 个月前
我和我的朋友们正在尝试了解一个特定的细分市场是否真的存在,或者我们是否在想象一个大多数人已经用其他方式解决的问题。 我们特别寻找这样的人/团队: 1. 自托管他们的数据库(例如,Postgres) 2. 通过 SSH 登录机器和/或运行自动化脚本来管理它 3. 仍然需要更高级的功能:PITR(时间点恢复)、PgBouncer(连接池)、可观测性、复制等 我们正在构建一个通过 SSH 预置和管理数据库实例/集群的工具。可以想象成“超级增强的自托管数据库自动化”,但不需要 Kubernetes、Docker 编排或全栈 PaaS。本质上:类似托管 Postgres 的用户体验,但适用于希望留在自己服务器上的人。 目前,我们陷入了两难境地: 1. 一方面,我们没有看到任何类似的产品,除了 Crunchy Postgres,它非常注重企业级。 2. 另一方面,我们不确定缺乏产品是否意味着市场不需要这个,或者工程师们是否只是因为没有轻量级的选择而被迫手动完成所有事情。 我们目前看到的替代方案: 1. Kubernetes Operators – 功能强大,但需要承诺使用 K8s。 2. Crunchy Postgres – 很好,但非常面向企业。 3. 全栈部署平台(Coolify、Dokploy 等)– 用户体验不错,但当您需要 PITR、PgBouncer、逻辑/物理复制、深度监控等时,功能有限。 4. 完全自管理 – 这意味着大量的 SSH、脚本、cron 作业、自定义备份,以及扮演“意外的 DBA”。 我们正在尝试弄清楚: * 工程师们是否真的需要一个通过 SSH 处理高级数据库生命周期管理的工具? * 或者,期望是如果您需要这些高级功能,您应该使用云托管数据库或 Kubernetes 数据库操作员? * 如果您今天自托管数据库,运营开销有多痛苦?您的工作流程是什么样的? 我们很乐意听取任何符合(或曾经符合)这一类别的人的意见,或者任何对这是否是一个真正的问题有强烈看法的人的意见。如果人们感兴趣,很乐意分享更多细节,但主要试图验证这是否是一个值得继续深入研究的兔子洞。
查看原文
My friends and I are trying to understand whether a particular niche actually exists or if we’re imagining a problem that most people have already solved another way.<p>We’re specifically looking for people&#x2F;teams who:<p>1. Self-host their own database (e.g., Postgres)<p>2. Manage it by SSH-ing into the machine and&#x2F;or running automation scripts<p>3. Still need more advanced features: PITR, PgBouncer, observability, replication, etc.<p>We’re building a tool that provisions and manages database instances&#x2F;clusters over SSH. Think “supercharged self-hosted DB automation,” but without requiring Kubernetes, Docker orchestration, or a full-stack PaaS. Essentially: managed Postgres-like ergonomics, but for people who want to stay on their own servers.<p>Right now, we’re stuck between a rock and a hard place:<p>1. On one side, we don’t see any product like this, except Crunchy Postgres, which is very enterprise-focused.<p>2. On the other, we’re not sure whether the lack of products means the market doesn’t want this, or whether engineers are just stuck doing everything manually because there isn&#x27;t a lightweight option.<p>Current alternatives we see:<p>1. Kubernetes Operators – powerful, but require committing to K8s.<p>2. Crunchy Postgres – great, but very enterprise-oriented.<p>3. Full-stack deployment platforms (Coolify, Dokploy, etc.) – nice UX, but limited when you need PITR, PgBouncer, logical&#x2F;physical replication, deep monitoring, etc.<p>4. Fully self-managed – which means a lot of SSH, scripts, cron jobs, custom backups, and playing “accidental DBA.”<p>We’re trying to figure out:<p>• Do engineers actually want a tool that handles advanced DB lifecycle management over SSH?<p>• Or is the expectation that if you need these advanced features, you should either use a cloud-managed DB or Kubernetes Database operators?<p>• If you are self-hosting databases today, how painful is the operational overhead? What does your workflow look like?<p>We’d love to hear from anyone who fits (or used to fit) into this category, or anyone with strong opinions on whether this is a real problem. Happy to share more details if people are interested, but mostly trying to validate whether this is a rabbit hole worth continuing down.