At PeerDB, we are building a first-class data-movement tool for Postgres, initially focusing on a fast and cost-effective way to replicate data from Postgres to Data Warehouses. We initially started by building PeerDB as an extension, but later changed our direction to develop it as a standalone Postgres tool rather than an extension. I wanted share the framework that we used to decide against building PeerDB as an extension. It will be useful for any Postgres company or developer evaluating whether to build their product as a Postgres extension or not:<p>We asked ourselves 3 main questions:<p>Is the PostgreSQL dialect necessary for this use case? The use case in question involved data movement, and the PostgreSQL dialect wasn't designed for that purpose. We received similar feedback from users. They preferred a simple and intuitive UI over a collection of UDF functions for replicating data from Postgres. If we were building a database like Citus or Timescale, offering a PostgreSQL dialect would be much more sensible!<p>How does building an extension affect the distribution strategy? Our target audience consists of Postgres users with either managed or self-managed deployments. If we were to create an extension, existing managed services like RDS might not easily support it, preventing managed service users from using PeerDB. We could develop a separate Postgres managed service that includes the PeerDB extension. However, this would pose a significant barrier for customers, as they would likely not prefer migrating their operational database just for an improved data-movement experience.<p>Does the technical debt of building and managing an extension justify the value it provides? As we were developing a data-movement tool interacting with multiple non-Postgres databases, we needed to choose a programming language that was both native and versatile in driver support. We selected Golang, as it offers more native support for both Postgres and Data Warehouses than C, C++, or Rust. Writing extensions in Go isn't straightforward. Indeed, we could have managed an external server (in Go) responsible for data movement and used GRPC for communication with that server from Postgres. However, this would involve managing multiple components and complicating the tech stack. Considering our answers to Questions 1 and 2, we thought it wasn't worth it.<p>To sum it up, deciding if a product should be a Postgres extension or its own thing really boils down to what you're trying to do. It's all about what works best for the job, how it fits with different types of users, and how much hassle it is to build and keep up.