51–60 of 158 posts
For a really nice client for macOS see Postico: https://eggerapps.at/postico/ (not affiliated, just a fan)
It's mentioned and linked in the article. And "[i]t’s made by the same people that maintain Postgres.app."
Hopefully a few other people have had their lives made a tiny bit easier by the redirect I set up.
I love postgres.app, such a great solution. It always bothered me though that https://postgres.app would just 404 whenever I'd go to look up the docs or go to install on a new machine. Hopefully a few other people have had their lives made a tiny bit easier by the redirect I set up.
It looks nice for beginners but personally I find that a simple docker-compose file per project that spins up a postgresql container works pretty nicely and is really easy to use. I just run `docker-compose up -d` and I have a database running. Docker containers also stay out of the way of the os and I can run the right versions for whichever project.
I think you and this app are solving quite different problems. For you (and most people replying) it sounds like PostgreSQL is a component in a larger app that will eventually get deployed and run somewhere else and only be interacted with via that app. Others (like myself) use PostgreSQL as a local datastore and analysis engine. All my interaction with the database is via ad hoc SQL commands and locally run scripts…
No, they're not. You both just want a Postgres instance you can access locally. The major difference is that Postgres.app does not seem to do a good job of separating different databases.
> All my interaction with the database is via ad hoc SQL commands and locally run scripts and desktop applications.
You can do this with DBs built by Docker as well, with the added benefit that you can erase and rebuild them whenever you want, and they're separated by project.
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 \ -…
> because then everything is nicely isolated This is why we use SQLite for all the things. I don't even remember what a database installation process looks like anymore. It's just a nuget dependency and some code for us.
I would recommend DBeaver as a good client/IDE as well.
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'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’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.