Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres.app

postgresapp.com

Post reply on HN
Print view View original

131–140 of 158 posts

Re: Postgres.app

#131

Post by handrous »

Kaze404 wrote: post #60
ramraj07 wrote: post #58

Earlier quoted context omitted.

I’m yet to see people who use docker for development do it faster than People who don’t. They always end up having to mount specific folders etc which nullifies the isolAtion point and you lose so much because even something as simple as ide debugging becomes a complicated (if not impossible) task.

You don't have to use Docker for everything. I personally use Docker for services my application needs (Docker, Redis, etc) and Nix for the application itself.

I do something similar (minus the Nix part). I don't bother to dockerize my applications, but I use Docker as a cross-platform dependency manager for daemons they use. Before that, I used Vagrant with a full VM, which has the benefit of looking more like a provisioning script for a full server, but the down-side of being tied to whatever OS or distro you choose for the VM.

Either way, it's a way to document exactly how to get your dependencies in order and the project running. That's a big improvement, operationally, at a lot of places. If Docker died tomorrow with no replacement, I'd go back to the Vagrant thing. Installing that stuff directly on my workstation sucks, for a bunch of reasons, and I'll not go back to that if I have any way to avoid it.

Re: Postgres.app

#132

Post by GordonS »

afavour wrote: post #68
elnygren wrote: post #12

I've always preferred Docker for setting up databases and database-like services on a development machine because then everything is nicely isolated. i.e no need to worry about random files in /etc/foo, easy to setup many versions per project etc. This is what I've been using for Postgres: docker volume create postgres docker run -d \ -p 127.0.0.1:5432:5432 \ -v postgres:/var/lib/postgresql/data \ --name postgres \ -…

I went down this road for a long time and eventually realised I was gaining very little from it and picking up a bunch of downsides. Obviously everyone’s experience is different because we’re all doing different things but I mostly work with Rust and Node, I use Postgres.app as a local dev database and just run the code natively, sometimes Node via nvm when I care about specific runtime versions. It works great. It p…

I find Docker great for dev and test, as I can spin up and destroy databases from scratch in seconds - pretty useful for running tests in CI too. Also, the Docker image runs migration scripts at startup if needed, which is pretty useful.

Over in production, being consistent with dev is really nice, and having a consistent upgrade experience is a good benefit too.

Re: Postgres.app

#133

Post by GordonS »

berkes wrote: post #112
NelsonMinar wrote: post #96

Earlier quoted context omitted.

Let's see... the user could download an app, click it, and run Postgres. Or they could figure out how to install Docker, then run a terminal, then type two obscure and inscrutable commands into it. Perhaps administrator privileges are required along the way. Sure, the Docker route is better in many ways. But perhaps you're not understanding the audience for a packaged Mac application.

As long as postgres is your only external service, this is fine. But looking at my docker list of auxillary services for 8 projects, I see redis, postgis, postgres 10, postgres latest, memcached, mailcatcher (fake smtp), ldap, a custom oauth, kafka, MySQL, piwik(matomo), in various forms and configs. Sure, abstraction layers and adapters keep many such dependencies out of the way in Dev and testruns. But the inevitab…

A bit OT, but what are you using for LDAP?

Re: Postgres.app

#135

Post by bob1029 »

scns wrote: post #93
joshmarlow wrote: post #72

Earlier quoted context omitted.

Thanks for the details. I would be afraid to use SQLite over Postgres as SQLite is much more... flexible with it's database constraints (or at least, this used to be the case). Not knocking your engineering choices - if you've been running it in prod for years, then it's working for you - just interested. Do you lean into DB constraints much or do you do more application level checking/enforcement?

Not parent but mentioning nuget suggest parent is on dotnet, ie C/F# ergo semi-/typesafe. Parsing (not validating) at the edges should take care of it.

> Parsing (not validating) at the edges should take care of it.

Precisely. We use a tiny ORM on top of Dapper to make sure everything goes in and out of columns as expected.

Re: Postgres.app

#136

Post by evaneykelen »

If you like to use the ‘pg’ Ruby gem in conjunction with this app then you need to use `gem install pg -- --with-pg-config=/Applications/Postgres.app/Contents/Versions/X.Y/bin/pg_config` where X.Y refers to the correct version (IIRC you can also replace the version nr by `Latest`).

Re: Postgres.app

#137

Post by vhiremath4 »

nightpool wrote: post #46
elnygren wrote: post #12

I've always preferred Docker for setting up databases and database-like services on a development machine because then everything is nicely isolated. i.e no need to worry about random files in /etc/foo, easy to setup many versions per project etc. This is what I've been using for Postgres: docker volume create postgres docker run -d \ -p 127.0.0.1:5432:5432 \ -v postgres:/var/lib/postgresql/data \ --name postgres \ -…

I love using Docker Compose in theory, but I've found it really difficult to do local development with a "Docker only" setup on Mac, due to the performance issues with the filesystem layer (even when using cached volumes, etc). Ruby gemfiles and node_modules are big culprits here, since they involve a lot of filesystem accesses to load/install dependencies. It might be more manageable if I was just using Postgres fro…

This is off-topic, but I feel this more for live reloading/watching of rebuilding a node/webpack app vs. databases. For databases locally, I'm doing so little write usually that it's not a big deal. For coding and recompiling/hot reloading it's a big deal, and the perf is a pain. I really love working with Docker, so I hope they make the Mac experience more friendly soon.

Re: Postgres.app

#138

Post by mekster »

Why do people consistently try to run dev tools on their local OS when there are plenty of easy and cheap alternatives to accomplish more stable, reliable and reproducible environment?

Just get a $5/mo cloud instance and run your stuff as same OS as production and let other people check your environment even while your machine is turned off and continue working on another machine without duplicating the environment.

If you still want it locally, use VMware fusion which became free for personal use lately and run a real Linux like your servers do.

I see no benefit in running stuff on local OS.

Re: Postgres.app

#139

Post by vosper »

mekster wrote: post #138

Why do people consistently try to run dev tools on their local OS when there are plenty of easy and cheap alternatives to accomplish more stable, reliable and reproducible environment? Just get a $5/mo cloud instance and run your stuff as same OS as production and let other people check your environment even while your machine is turned off and continue working on another machine without duplicating the environment.…

> I see no benefit in running stuff on local OS.

A database on localhost is the fastest way to run your tests that need to talk to a DB.

Re: Postgres.app

#140

Post by mekster »

elnygren wrote: post #12

I've always preferred Docker for setting up databases and database-like services on a development machine because then everything is nicely isolated. i.e no need to worry about random files in /etc/foo, easy to setup many versions per project etc. This is what I've been using for Postgres: docker volume create postgres docker run -d \ -p 127.0.0.1:5432:5432 \ -v postgres:/var/lib/postgresql/data \ --name postgres \ -…

I trust OS packages for main daemons like database, smtp, http daemons.

How are you meant to apply only security patches on docker containers?

What's the point of "isolating" daemons to avoid "random" files in /etc?

It just makes it harder to git control and back up /etc by splitting it all over the containers.

Post reply on HN