Inquiry About Production-Ready Operational Features for Self-Hosted Version

[grapemix]

Hi team,
Congratulations on building what looks like a promising project. I've been reviewing the documentation and can see the potential of Helix DB, but I'm struggling to find information about production-level operational features or even a roadmap for them. This gap is concerning—not just for me, but potentially for other evaluators who might interpret the absence of clarity around operational capabilities as a lack of real-world infrastructure experience.

Why operational features matter for adoption

Enterprises pay premium prices to providers like AWS because they trust their data is secure, their services are reliable, and they can scale seamlessly when needed. For databases specifically, data is one of a business's most valuable assets, and user adoption is critical for any database project's success. I'd love to understand what the Helix DB ecosystem looks like in your team's vision.
As any senior developer knows, switching databases is a massive undertaking. Unlike adopting Gremlin, Cypher, or GraphQL where alternative options exist, building a system around HelixQL creates significant lock-in. If we need to migrate away, we'd essentially be rebuilding everything from scratch. This makes the decision to adopt Helix DB one we need to approach very carefully.

The path from POC to production

Many users like myself start with POCs or side projects. When these succeed, we evaluate the stack under production load, recommend it at our jobs, or even choose it for our startups' managed platforms. But here's the challenge: we can't accept our carefully built systems going down due to database backup/recovery issues, horizontal scaling failures, or HA problems.
We need to see these features working with our own eyes and validated by the open-source community—not just promised in an enterprise-only version that we can't evaluate until after we've committed.

Specific feature questions

Could you please clarify whether the following features will be available for the self-hosted/community version, enterprise-only, or aren't planned at all?

1. backup/recovery
   a. continuous backup and recovery without downtime like WAL
   b. Point-In-Time Recovery (PITR) and Recovery Point Objective (RPO) support
   c. able to store in S3 compatible object layer
   d. encryption at rest
2. Infrastructure as Code (IaC) and k8s friendly
   a. Instead of using cli to deploy, support operator like https://cloudnative-pg.io/ . If operator is too complicated, don't use helm chart. I can show you more if you are interested.
   b. support something like Horizontal Pod Autoscaling (HPA)
3. HA ready
   a. horizontal scaling support
   b. multiple concurrent writers
4. Open source dashboard(grafana), trace(Tempo), log(loki), alertmanager support
   a. dashboard https://grafana.com/grafana/dashboards/20417-cloudnativepg/
5. Fine grinded permission
   a. in RBAC, ABAC, tbl lvl, field lvl
   b. OPA's rego(https://www.openpolicyagent.org/docs/policy-language) + IdP integration

A suggestion on ecosystem integration

Rather than reinventing the wheel, consider integrating with the stacks and ecosystems that enterprise open-source users already run. This approach typically accelerates adoption among organizations that are cautious about introducing new infrastructure components.
What we're asking for
I understand the team is likely focused on tuning the core engine, and I don't expect all these features to land soon. However, it would be incredibly helpful to see:

• Your roadmap and what you plan to offer in the open-source/community version
• Any constraints or limitations on the self-hosted version
• Your pricing model for the fully managed service (CPU/memory? instance count? vector count?)
• Any specific cloud platform?

If any of our projects succeed, choosing the official managed service would be the obvious path—but only if we can validate the operational capabilities in self-hosted environments first.
Thanks for considering this feedback. I'm genuinely excited about Helix DB's potential and hope to see it succeed.

(PS: Yes, this msg is polilshed by AI, but 100% drafted by me)

[xav-db]

Hey man apologies for the delay in getting back to this.

Thanks for bringing this up. Below is information about our enterprise roadmap.

We are working on a new hyperscalable database implementation. It will support the following in the short term:

• Horizontal and vertical scaling (HA)
• The ability to store in S3 compatible object layer
• Encryption at rest
• Backups and point in time recovery
• Multiple concurrent write requests (only 1 writer node though)
• A Dashboard
• RBAC

All of the above will be enterprise only for the time being (either managed or self-hosted).

In the long term, we will work with customers to expand features and support more use cases as the need arises.

Thank you for the feedback, and your support!

Please let me know if you have any questions or concerns.