Today, we're open-sourcing Vela. A self-hostable, production-grade Postgres data platform built for people who actually want to run their own infrastructure without duct tape, shell scripts, or vibe-based SRE.
Open-source announcements usually start with something polite and reassuring, like "we're excited to share" or "this is an early experiment, but." This is not one of those announcements.
We deliberately forked Supabase, fully aware that it would make parts of the internet uncomfortable. Not because Supabase is bad. Quite the opposite. Supabase is excellent software and an incredible service. But excellence doesn't automatically translate into self-hostability or enterprise-readiness. Pretending otherwise is how you end up with YAML-shaped sadness.
We're far from "done" with Vela yet. Meaning, this is not a fully polished product announcement, but a request for feedback and an invitation for people who care about the systems they operate.
TL;DR: Why have we built Vela?
Today, PostgreSQL is the database of choice for most projects, including AI applications. Yet, there are only two ways to consume it. Either via a hosted cloud service, or via a Postgres installation that still feels like the 80's; minimal convenience and automation.
The idea for Vela started with the realization that the world is ready for a Postgres environment that delivers the convenience and ease of use of a cloud service combined with the security and compliance advantages only possible in your own "cloud" (BYOC, Bring Your Own Cloud).
We immediately thought of Supabase as a solution. A tool beloved by developers and vibe coders alike. But it's a cloud-only service. Furthermore, the open-source self-hosted version provides a single database only. Not necessarily an enterprise-level production database solution. It's generally a different version than the Supabase we love (as we learned along the way).
Since at simplyblock we already built an enterprise-grade, distributed, and high-performance storage system based on NVMe over Fabrics and SPDK, we started thinking how to combine "something like Supabase" with "something like simplyblock". Testing simplyblock's performance with Postgres made us understand the benefits that a combination of the two technologies would deliver. So, we went ahead and did it.
Vela is a Postgres-based platform that enables fast prototyping, testing, and scaling on your own rules and in your own environment. No matter if in the cloud or on-prem.
Vela provides immediate database snapshots, clones (branches), and a beloved Supabase-like user interface, and combines them with a robust orchestration layer to deliver the same convenience and ease of use you expect from a hosted service.
Forking shouldn't be taken lightly.
Let's address the elephant in the room: Why do you think it was necessary to fork?
Sometimes, the cleanest solution to a problem is to tackle it with a chainsaw.
As mentioned before, we love Supabase. We love Neon. Don't get me wrong, both products are great solutions. That's why we took the best parts of them. If we think either sucks, why would we build anything on top?
But.
Supabase (and Neon) are fundamentally SaaS-first platforms. And we learned it the hard way, trying to rebuild a scalable infrastructure around the Supabase Studio UI. Their architectural assumptions (like cloud providers and VM sizing), their guardrails (like hardcoded hostnames), and their trade-offs (like IPv6 and IPv4 restrictions) make perfect sense when you operate it as a hosted SaaS platform. These make less sense if you want to operate it. Unfortunately, self-hosting wasn't a first-class path. It was a side quest. While the code is open-source, it's not really usable for the broader community.
Forks aren't about preserving upstream purity. They are about being able to say, "This problem needs a different solution." About being able to write code to prove your point.
Vela is our answer to the honest question about how to run Supabase. On-prem. In a private cloud. In your own cloud account. On bare-metal. Wherever you want. At scale.
If you have strong opinions, we want to hear them. We want to listen.
If you want to try it out, we have a public sandbox updated multiple times a day with the latest builds: https://demo.vela.run.
If you want to contribute, all repositories are public. Find the list at the end of the blog post.
Forking Supabase: What We Didn't Expect
When we started Vela, we assumed that we would mostly reuse Supabase's open-source codebase. Maybe patch a few rough edges and focus on our orchestration layer. That assumption lasted about as long as our first serious attempt to run it as a real, self-hosted production platform.
What followed were months of deep refactoring, deletion, and re-architecture across identity, orchestration, storage semantics, logging, provisioning, and even how a "database" is defined in the system.
During that period, we removed approximately 350,000 lines of cloud-specific code from the repository (out of 1.4 million lines), along with documentation, website content, and related elements. Furthermore, about 200,000 lines of code (excluding OpenAPI specs) were added, and 67,000 lines of code were modified to restore missing Supabase components for self-hosted installations.
No Postgres Platform without Postgres Storage
Let's talk about the thing almost no Postgres platform wants to talk about in public: storage.
If your platform advertises instant branching, cloning, PITR, HA, and replicas, but has no strong opinion about storage, it is quietly lying to you. Logical replication, pg_dump gymnastics, or snapshotting at the cloud-provider layer can get you surprisingly far, but they fall apart the moment you push density, frequency, or scale. Not to talk about deployments outside the cloud.
Great solutions like Btrfs and (Open)ZFS help a lot, but are limited to a single host. ZFS, at least, enables you to use iSCSI remote connection. But please don't make me talk about iSCSI. A technology released when Windows 2000 was bleeding edge. NVMe over Fabrics is the future.
Anyways, since simplyblock started out as a storage company, it made sense to integrate our storage engine at the core of the system. Not in a way that we rely on it (it is totally possible to add support for Btrfs, ZFS, and other storage systems), but as the first-class citizen required to provide a vast set of features expected from a modern data platform.
Simplyblock provides a software-defined NVMe over Fabrics storage engine, designed specifically for snapshot-heavy, copy-on-write workloads. Sounds like database branching to me.
And when I say "branching," I don't mean "copy a database and wait." We mean a metadata operation backed by storage-level snapshots.
When I say "clone," I mean that the underlying blocks are shared until they diverge.
Vela treats storage as something the database depends on; semantically. Clones, backups, PITR, HA. All features that directly depend on the storage layer to provide the required capabilities for Vela.
Rebuilding a Core Architecture: We Need a Platform Kernel
When we started dissecting the Supabase source code, coming up with a plan of attack, we found a lot of things that we removed first. We knew that there was a lot of rework on the horizon, and the easiest code to rework is the code that's gone.
We removed SaaS-only features. We removed tracking. We removed entire subsystems related to plans and payments. We removed legacy screens that existed only because nobody wanted to touch them. We removed environment variables whose only purpose was to enable slightly-hacked (at least from the look of it) support for alternative cloud environments such as Fly and Vercel.
Claiming the codebase is pristine would be overstated, though. It is far from it. Still, there are lots of unused or rewritten pieces left around in the codebase. We're not pretending otherwise. Cleaning up a codebase is a massive undertaking.
The Supabase source code grew organically. Over many years. Cleaning it up isn't always the first priority. Especially when investors are interested in other metrics. We, however, had the chance to clean up the codebase on the go.
Branches Are Actual Databases
In Vela, a branch isn't anything you run locally. It's not just another database in the same Postgres process. It's a self-contained, independent Postgres database instance, encapsulated in a virtual machine.
Every branch can be created empty, cloned with configuration only, cloned with data, or cloned fully. Every branch has resource limits, usage accounting, and its own lifecycle.
Environments exist as organizational constructs that group branches for permissions management, backups, and operational sanity.
While this sounds simple, combined with the copy-on-write power of modern storage solutions, such as simplyblock, it provides full isolation of production, staging, and development instances, while sharing as much underlying storage as possible.
10 Seconds Boot Time Thanks to Neon Autoscaling and VelaOS
But this is only the Supabase Studio part. We also updated or exchanged a lot of other, deeper components of the system.
Early versions of Vela experimented with KubeVirt to support seamless migration paths. That approach taught us a lot. Mostly about where KubeVirt still struggles with reconciliation, unsupported features, and operational complexity at scale. We ended up writing workarounds to update CPU and memory past KubeVirt, knowing that the next reconciliation would override our changes. Not great, especially for an all-new system infrastructure.
While trying to figure out if forking and eventually upstreaming KubeVirt would be a viable solution, we found an alternative. Neon's Autoscaling project. And that one, hands down, is incredible. We still had to make small changes, but we hope to upstream them soon.
So we moved to an autoscaling-based system. It is still based on QEMU, but provides far better control over the lifecycle and integration with our controller. Like I said, credit where it's due: Neon's work here is excellent, and we're grateful it exists.
Inside the virtual machine, we use Vela OS. A minimal system image built using Buildroot, a Linux kernel, and a rootfs build system widely known and used (partially) by systems such as Home Assistant OS (HAOS), OpenWRT, and many embedded systems vendors, including Google Fiber.
This combination of QEMU-based Postgres virtualization, storage-level snapshots, and controller-driven orchestration is what allows Vela to treat databases as elastic, ephemeral resources without pretending Postgres is stateless.
Making Authentication, Authorization, Identity Boring
Supabase, at least in its open-source deployment, uses a forked version of GoTrue, called Auth. It's a Go-based identity management solution that works great. But to host multiple tenants, you need multiple running instances.
Additionally, it's not necessarily a widely used solution. For enterprise-grade identity management, we wanted to go the safe route. We wanted something boring. We wanted industry-proven. We wanted Keycloak.
Keycloak is boring in the best possible way. It supports multitenancy, SAML, OIDC, MFA, passkeys, and the sort of compliance checklists enterprises and security-focused individuals bring to the table. Rebuilding auth is fun until auditors show up.
From the Vela side, we extended Keycloak's sessions with RBAC (Role-based Access Control) to support a three-level hierarchy (organization, project, branch) with permissions and environment-based grouping. At the moment, permission assignment is only additive, but that will change in the future. For now, that is good enough, even though still not great.
Logging with Logflare: Another Unsexy Decision
Supabase uses Logflare. A product Supabase acquired in 2021. While it is a cool project, it's not perfectly suited for self-hosted installations.
Logflare, in Supabase OSS, uses a special "Supabase mode" which enables a half-baked Postgres log storage. By default, Logflare will store to BigQuery or Clickhouse. Both are great options in the cloud or if you already operate a Clickhouse cluster. Tbf, we didn't test much with the Clickhouse backend since we're a Postgres platform, why would we want to use Clickhouse?
Anyhow, we replaced Logflare with Loki. An open-source component, well-known and beloved. In addition, we use Grafana for observability of our PostgreSQL and PGBouncer services.
Log collection still uses DataDog's Vector project, which is also used by Supabase and Neon. We all seem to agree, it's amazing!
Our choices aren't flashy. They are pragmatic. And we love it that way. Use great components that are known, used, and beloved by many people.
Vela's Orchestration Unit
Supabase OSS was never meant to talk to more than the local Docker-provided databases. Much of the codebase has feature flags, such as IS_PLATFORM, to enable or disable whole sections of the product or change the behavior of functions. One example, the organization and project data. Supabase OSS pinned those to static data being returned from a "fake-backend layer".
For simplicity, and because it took way too long to really understand the premise of this fake-backend, we started to implement proxies from Vela Studio (the frontend part), to the Vela Studio backend part, to our all-new internal orchestrator called vela-controller. This approach felt right at the time, until we realized that more and more calls were missing because they were never called in the self-hosted environment.
While the proxies were very helpful while migrating and cleaning up certain data structures, they are mostly just one-to-one forwards by now. Slowly but steadily, we'll remove those proxies and integrate straight calls into the controller from the frontend. This will further clean up the codebase and simplify future maintenance.
Postgres Extensions (Because You'll Ask)
Postgres is an incredibly extensible platform. It's one of the reasons why I love it so much. However, that means those extensions need to be available for you to use.
Vela already supports a good number of extensions out of the box. Not all of them, though. There are over 400 of them, and we don't just want to bloat the database.
We looked at many other providers of Postgres and believe we started with a good set of the most used and beloved extensions, including:
A full list of all available Postgres Extensions can be found in the preliminary Vela documentation.
If you feel there is an important extension missing, please reach out!
Where This Is Going (and Where It Isn't Yet)
Vela isn't "done," it's not even close to be done. High availability, read replicas, and snapshot-based PITR are actively being wired together.The roadmap is ambitious. But we want to primarily shape it based on user feedback.
The storage primitives exist, but the orchestration still needs polishing, and so needs provisioning reliability, potentially with Temporal.
Likewise, data pipelines, with upfront data anonymization and live transformations, are on the roadmap.
Last but not least, the installation is still rougher than we'd like it to be. That's why the sandbox is a great way to eat your own dogfood without building a full hosted service. In the future, Vela will use Terraform or Ansible as the main installation method, combined with a new Kubernetes operator, which will supersede the first incarnation of vela-controller.
Being a good member of the open-source community is important to us, though. That's why, over the next few weeks, we will begin upstreaming changes to the respective projects. While many changes for Supabase will be hard to upstream, we’ll definitely try to integrate our changes with the upstream Neon’s Autoscaling repository. Important changes include support for soft-limiting virtual machine resources, powerState implementation, and additional block storage volumes.
Additionally, Vela OS may be of interest to the broader community. As a minimal Buildroot-based operating system, it is easy to build and extend, and enables quick iteration. It's a widely used alternative to Neon's Docker-based custom build system and already supports SystemD, which simplifies many tasks over the current initd system.
Try It. Break It. Tell Us.
I can only reiterate, we love Supabase. We love Neon. This fork exists because of their work, not in spite of it.
But open source is not a promise to never disagree. It is a promise that disagreement can turn into better software instead of angry comments. Forks are not betrayals. They are how ideas and solutions evolve when constraints change.
We believe in strong communities, even across forks. If parts of what we've built make sense upstream, we'll try to upstream them. If they don't, we won't force it. Vela exists to answer a question neither Supabase nor Neon is trying to answer: "What does a serverless Postgres platform look like when you run it on your own servers?"
That said, if you want to try it out, feel free to play around with our public sandbox. We aim to keep it as stable as possible, but it is not intended for production and will be updated frequently.
The code is available split into multiple repositories:
All code is either Apache License 2.0 or MIT licensed.
If you want to leave feedback, report issues, or request additional features, please use the issues at the Vela Studio repository. We are looking forward to all kinds of feedback. We're still actively building, and the only meaningful way forward is with your feedback.
If you try to find us, we're over here deleting more code and booting databases in seconds instead of minutes.