Heroku Releases Free PostgreSQL App for OSX
techcrunch.com
techcrunch.com
http://postgresapp.com/ https://github.com/mattt/PostgresApp
Postgres.app is the easiest way to get started with PostgreSQL on the Mac. Open the app, and you have a PostgreSQL server ready and awaiting new connections. Close the app, and the server shuts down.
Postgres.app will be distributed through the Mac App Store, with a separate build containing the latest PostgreSQL beta available for direct download from the website.
Done. How is this useful?
What happens when you're trying to compile native libraries for your high level language?
We saw that many developers were using SQLite (or MySQL) on their local machines, but Postgres on Heroku. This led to frustrating and hard to diagnose bugs and behaviors in their apps. Our hypothesis is that easier local install will lead to more widespread usage for the technology.
Let me try to articulate my point, but I could probably use some help:
I suspect that the sort of developers who were writing apps and using SQLite locally but deploying with Postgres were the sort of developers whom will still use shaky and poor development and deployment practices regardless of whether or not Postgres is available to them locally.
Orthogonally, I think that the kinds of developers who will actually take the time to follow best development and deployment practices probably wouldn't want to use an app like this - not because it isn't a nice and helpful app, but because they probably want to install the full always-on server bundle via 'brew'.
That's my guess anyway. Does this mean the app was a bad idea? No, definitely not. But I don't personally expect a huge uptick in Heroku deployment quality because of it. At least it definitely won't be for lack of trying!
No doubt this app will appeal to the more casual developers. When the low-end of Dell is a 4-core x86-64 with more memory than most people will ever need, most non-casual developers who need to write code specific to a given database will have it starting up on boot.
Postgres performs and behaves differently too. Developers will be more conscious of vacuuming and analyzing their DBS, especially after large deletes, etc.
Overall it removes friction, regardless of how trivial, and helps commoditize the whole development and deployment cycle which is essentially herokus entire value proposition.
I say great work.
This. I'm just getting started playing with Heroku as a hobby. I've not used Postgres before, so getting things set up correctly on my dev machine was not a "install one app, go" kind of experience. I spent at least an hour reading / trying / understanding. Having something like this would have meant 1 more hour of making, rather than trying to get Postgres setup.
For hobby (or any) projects, 1 extra hour doing what I want to do is a big deal. I'm only able to spend about 5 hours per week on my hobby, getting 20% of my time last week back would have been a big deal to me.
If your goal is something that can easily and obviously be uninstalled completely, the App Store version sounds like exactly what you're looking for; Apple is pretty strict about what an App Store app can and can't do outside its sandbox.
Otherwise, I've been using the binary installers from PostgreSQL.org on OS X for years, and they work fine. They install everything into /Library/PostgreSQL, so they're self-contained, and the server starts/stops/can be set to auto-start easily with launchctl.
Now I have 2 options. I can continue googling this error and trying all the random solutions (fyi, none of them worked, and I spent a solid 2 hours trying all of them) or I can install postgresql.app and get back to doing actual work. I chose #2.
Even uses MacPort's pre-built binary packages, so I don't have to wait for the compile.
The application GUI is still useful for some people that don't otherwise need MacPorts or homebrew.
Thanks to the developers who put the app together.
Anyhow, start the app, open a psql shell with /Applications/Postgres.app/Contents/MacOS/bin/psql in a terminal window, and you get a session. Since (I think) the app is intended only for development use, I'm not sure if they intend for you to change those defaults. That's not to say that you shouldn't but just that the app is meant to be (nearly) zero conf. (The documentation suggests adding Applications/Postgres.app/Contents/MacOS/bin to $PATH, which is probably a good idea if you will use the command line tools often.)
So n other words, since they didn't bother telling us the user/password, this app is useless. Better off using MacPorts.
The /Application folder itself is owned by root:
achilles /$ ls -ld Applications/
drwxrwxr-x+ 55 root admin 1870 Jul 20 06:54 Applications/
achilles /$ ls -ld Applications/Postgres.app/
drwxr-xr-x@ 3 achilles staff 102 Jul 18 20:17 Applications/Postgres.app/
achilles /$ /Applications/Postgres.app/Contents/MacOS/bin/psql
psql (9.1.4)
Type "help" for help.
achilles=#
PS. and pardon me for being rude - it was late and was filled with too much cheap wine.
"Induction supports PostgreSQL, MySQL, SQLite, Redis, and MongoDB out-of-the-box"
A bit uglier but if you need to support quite a few databases maybe Razor is another good alternative. I've used it for years. It is not open source though.
It works on Windows, OS X and Linux, connects to almost any RDBMS in existence, easily customizable and has tabbed results interface in addition to many other features.
All for $60-70. Easily worth the money, you can get a full trial for 30 days to see if it works for you.
I use it a lot, and have nothing but praise for it.
I'm still holding out for Postgres and Sqlite support in Sequel Pro since that tool has a great UI and tons of nifty features.
I do like having macports (or homebrew, I guess) on the mac for tools like mutt, curl, wget, nmap, etc., but I'd prefer to run a whole virtual front end server talking to a virtual db server and use local clients on the mac to connect.
(I really wish I had more than 4GB RAM in my Air, though, but don't want to replace this one so soon)
If your app is at the deployment to production stage, then I would strongly recommend using the same database as will be used in production. This quote isn't actually saying what proportion of developers don't do that, though.
I'm sure anyone working through Michael Hartl's Rails Tutorial right now and trying to do the optional Postgres configuration is also pretty excited at the time savings.