Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an easy way to run PostgreSQL locally #229

Closed
dhess opened this issue Jan 24, 2022 · 1 comment · Fixed by #230
Closed

Add an easy way to run PostgreSQL locally #229

dhess opened this issue Jan 24, 2022 · 1 comment · Fixed by #230
Assignees
Labels
database Database/persistence issue enhancement New feature or request priority: high This issue has high priority

Comments

@dhess
Copy link
Member

dhess commented Jan 24, 2022

When we replace Selda (see #201), we'll likely lose SQLite support. Therefore, we'll need a relatively low-friction way to spin up local PostgreSQL instances for local development.

Having considered several solutions and their tradeoffs, I think the best overall approach will be to use Docker to run a local PostgreSQL instance(s), over which the developer will have full control, including the ability to create, migrate, and delete development databases in isolation from any other users.

Alternatives

There are a few alternative solutions we could implement. However, I believe they all have too many drawbacks vs. the Docker solution.

Run PostgreSQL as a local OS service

Though it requires the least amount of extra software to install and configure, running PostgreSQL as a local OS service isn't a good idea. In addition to being non-portable (and it would only be feasible to maintain such a solution for macOS and NixOS), it would invite all sorts of security issues. I think this solution is a non-starter.

Centralized development PostgreSQL instance

We could run a centralized PostgreSQL instance for development purposes. Obvious choices for hosts are Fly.io, AWS (PostgreSQL RDS), and GCP (PostgreSQL Cloud SQL). This would require little to no setup for Hackworth Ltd developers (likely just starting a VPN), and we could distribute database secrets to developer machines via Vault Agent. Because the load on a developer database would be minimal, it could be hosted on a very small instance, in which case the costs would be negligible.

However, while this solution is suitable for the Hackworth Ltd team, the instance could not feasibly be made available to community contributors, who would need an entirely different solution. I'd rather have one mechanism that works for everyone.

Additionally, the need to set up & launch a VPN before testing, and the additional complexity of distributing & rotating secrets via Vault Agent, make this solution less appealing than using Docker.

@dhess dhess added database Database/persistence issue enhancement New feature or request priority: high This issue has high priority labels Jan 24, 2022
@dhess dhess self-assigned this Jan 24, 2022
@dhess
Copy link
Member Author

dhess commented Jan 25, 2022

#230 demonstrates that this is trivial to do with Docker, and probably even portable (assuming Colima works as advertised on Linux).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
database Database/persistence issue enhancement New feature or request priority: high This issue has high priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant