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

121–130 of 158 posts

Re: Postgres.app

#121

Post by SkyMarshal »

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 \ -…

Doesn't the OS X .app format package everything in a nicely isolated single file too? That's what it seems postgres.app does.

Re: Postgres.app

#122

Post by crazygringo »

bdcravens wrote: post #103
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.

I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. If someone finds terminal commands "obscure", I'd hate to see what their SQL looks like, in which case maybe they shouldn't be running a database server. For what it's worth, installing Docker on Mac (the audience we're talking about) is as easy as installing Postgres.app (download an installer and open). No administrator privileges necess…

> I think it's a bad take to assume that everyone using a Mac needs a 1-2 click.

Huh? Nobody said everyone using a Mac needs it. Where did you get that from? You seem to be putting words into GP's mouth.

But some people certainly could prefer it, which is the whole point of it existing, for those people.

Also, your comparison isn't even close to equivalent. It's not the ease of installing Docker vs Postgres.app... it's the ease of installing Docker and then figuring out how to configure an instance with Postgres vs Postgres.app. Obviously Postgres.app is easier. Some people have no need or desire to figure out Docker, they just want to use tools installed locally.

Re: Postgres.app

#123

Post by Macha »

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 use docker (well, podman) for postgres on my personal machine because it's the one package that causes me headaches in my rolling release distro. Postgres n -> n+1 always requires a migration process (and you can't shortcut n -> n+x), so if I spend a period of time not working on my Postgres using projects, I find I've updated from n -> n+2 or more and need to figure out how to get the old version installed again since it's a dependency of the migration tools to have both versions available.

Re: Postgres.app

#124

Post by theptip »

derefr wrote: post #99
brian_herman wrote: post #94

Earlier quoted context omitted.

I love docker I just get really confused when the networking gets involved in the mix. Like I tried to make a airflow cluster with docker and I gave up.

I’ve been burned by using Docker’s networking directly too many times to count, especially in the context of Docker for Mac (where “the host” sometimes means “your computer”, while other times meaning “the VM Docker runs in”, arbitrarily.) However, Kubernetes on Docker (microk8s or whatever it’s called) has always been extremely predictable in its (development-time, single-node) networking behaviour for me. Set up th…

Docker for Mac's builtin Kubernetes cluster keeps getting better. These days (as of a year or so ago?) if you create a LoadBalancer Service it will wire up the port forward to your Mac's localhost, which is really nice. If you set up a local CA cert (minica makes this easy) and add an entry in your hosts file like "127.0.0.1 localhost.myhost.com", you can actually get full HTTPS to your development pod, using a production-like LoadBalancer Service setup.

I haven't tried microk8s, does it do full Service proxying to localhost? I did try Minikube a few years back and the Service proxying wasn't implemented yet.

I'm a big fan of fully replicating the production-like environment (including TLS) in your dev setup, at least for iterating on k8s-layer config changes; taking the cycle time for k8s changes down to seconds makes for a very pleasant development experience.

Re: Postgres.app

#125

Post by Macha »

NelsonMinar wrote: post #96
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 \ -…

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.

I've used these type of apps which bundle a common infrastructure component and a management GUI on Windows before when starting out, back in the XAMPP / Apache2Triad days.

I found they'd cause more problems than they solved ultimately, as they didn't provide clear upgrade paths, often had opinionated default configs which left newbies wondering why public documentation didn't work, and there was a lot of churn as to which one were currently in vogue and maintained.

Re: Postgres.app

#127

Post by NelsonMinar »

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…

Eight projects, wow, you are very impressive. Good job! Perhaps you are not the audience for "The easiest way to get started with PostgreSQL on the Mac".

Re: Postgres.app

#128

Post by handrous »

mromanuk wrote: post #29
Trufa wrote: post #20

Earlier quoted context omitted.

That's interesting, but my situation is that I'm developing on macOS and deploying on a linux box so my postgres setup with docker can look virtually identical.

Why worry about one more level of abstraction, if using the same version of Postgres should be enough?

If you're using Docker on the server, too, then it saves you from dealing with package management & version availability across multiple operating systems or distros to ensure that everything's at the same version no matter where it is. Config also looks very similar and lives in a consistent location regardless of the platform, which is nice, and between the docker file and either the startup command or the docker-compose file, you've also got documentation for exactly where any important data for the dockerized service lives and can easily prove that you've located all the important data (destroy the container, bring it back up... still looks good, no data loss? Then it's all documented). Again, with a single tool, regardless of platform.

No one has to give any shits that Fred's workstation runs the latest Ubuntu and Sally likes Arch and John is on macOS and the server is Debian Stable. They'll all run the same versions of your project's service dependencies... and the correct versions of the other five projects you're all working on, which don't need to be updated in lock-step, and Amy the part-time remote contractor you just brought on doesn't have to have her machine polluted with actual installs of any dependencies for your project outside the repo itself, just easily-eradicated containers.

Re: Postgres.app

#129

Post by bdcravens »

crazygringo wrote: post #122
bdcravens wrote: post #103

Earlier quoted context omitted.

I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. If someone finds terminal commands "obscure", I'd hate to see what their SQL looks like, in which case maybe they shouldn't be running a database server. For what it's worth, installing Docker on Mac (the audience we're talking about) is as easy as installing Postgres.app (download an installer and open). No administrator privileges necess…

> I think it's a bad take to assume that everyone using a Mac needs a 1-2 click. Huh? Nobody said everyone using a Mac needs it. Where did you get that from? You seem to be putting words into GP's mouth. But some people certainly could prefer it, which is the whole point of it existing, for those people. Also, your comparison isn't even close to equivalent. It's not the ease of installing Docker vs Postgres.app... it…

Perhaps I worded it poorly, but I was addressing the idea "the audience for a packaged Mac application", which to me suggests a less technical user. Which is fine for non-dev tools, but I wouldn't consider a user needing a database to fall into that category. (though perhaps that's true of developers who don't write SQL, but only rely on an ORM)

> Obviously Postgres.app is easier

Not necessarily. I used Postgres.app prior to switching to Docker Compose. It's a great option if you work on one app, don't need to switch between multiple versions, and don't need to work with a lot of different extensions or configs. I personally prefer keeping all of my config in source code, in the context of my application.

Re: Postgres.app

#130

Post by jokoon »

theandrewbailey wrote: post #47
jokoon wrote: post #39

Why use postgre instead of sqlite?

Off the top of my head: Postgres is a client-server system, with full user access controls and multiple client connections. Postgres has PostGIS (geographic data) and foreign data wrappers. Postgres is more scalable than Sqlite and can work with larger datasets over multiple instances.

There's spatialite.
Post reply on HN