Hacker News Reader

Comment by craigkerstiens | Hacker News Reader

I'm a big fan of Postgres, and it's got plenty going for it. That's not to say Oracle isn't a good database in its own right. The knocks against Oracle tend to be lock-in, complexity, price, but rather than go in a checklist comparison I'd rather say what's unique about Postgres:

- Based on its license it's very hard for any one company or individual to "own" Postgres, this makes risk of a company as a bad actor being minimized pretty appealing

- Its geospatial capabilities put it as the most advanced geospatial database, only ESRI software really stands to beat it here

- The improvements for app devs from things like JSON, to a variety of index types put it in unique territory among relational databases

- The extension framework is truly unique and stands to be where a lot of future innovation happens.

View on HN

"Based on its license it's very hard for any one company or individual to 'own' Postgres"

I know you already know this, but it takes a lot more than just a license. I'd like to call attention to the very enlightened (and noble) work others have done to build a robust political structure and community for Postgres.

The core team, committers and major contributors are spread across many companies and continents. There are different foundations across different regions for handling finances, trademarks, domains, and other basic business operations.

Amazingly, a lot of this structure was being put in place a long time ago, when Postgres was still the weird database option to choose.

Worked on a large application for the Dutch government with Oracle as database using spatial. Oracle is the only database that implemented spatial wrong (in my opinion). Oracle is the only one that implemented spacial functions to have a parameter for the accuracy. So basically you spacial function could calculate things wrong depending on that parameter. We had issues in the calculations when we where subtracting land to see what parts we needed to buy from land owners for laying new roads. We could not fix this. Oracle didn't help. They payed millions for licenses but they did not offer enough support in my opinion. I did some of the calculations in postgres with the spacial extension and most of them where way faster (10 times was not uncommon). Postgres also did not fuck up the calculations like oracle did. The project actually had a huge amount of psql code and we could not switch to postgres...

> Its geospatial capabilities put it as the most advanced geospatial database, only ESRI software really stands to beat it here

Where does PostGIS stand in comparison?

Likely the OP means PostGIS where they say Postgres. PostGIS is the set of geospatial extensions for Postgres.

Correct, my intention was fully PostGIS == Postgres geospatial.

The original comment was about how few packages and how little space Postgres takes. PostGIS is good but it pulls in a lot of extra packages.

I hate Oracle as much as anyone but this is no longer a fair comparison. If you’re bragging about how good PostGIS is, you’re no longer anywhere near a 66MB install. More like (IIRC) 5 to 10 times that.

But even assuming the high end of your estimate, Postgres + PostGIS would still be less than 1/10 of the size of a baseline Oracle installation.

660 mb disk space?

I can afford that.

And I think that most people can.

For the record, on Debian unstable:

  root@pg1:~# LANG=C apt install postgresql-12 
  Reading package lists... Done
  [...]
  0 upgraded, 32 newly installed, 0 to remove and 0 not upgraded.
  Need to get 59.7 MB of archives.
  After this operation, 240 MB of additional disk space will be used.
  Do you want to continue? [Y/n] ^C
  root@pg1:~# LANG=C apt install postgresql-12 postgresql-12-postgis-3
  Reading package lists... Done
  [...]
  0 upgraded, 105 newly installed, 0 to remove and 0 not upgraded.
  Need to get 104 MB of archives.
  After this operation, 418 MB of additional disk space will be used.
  Do you want to continue? [Y/n]

I think the addition of LLVM for JIT execution of plans added a lot to the Postgres install baseline (at least in distribution packages, you can compile a much leaner postgres yourself).

Due to the way that the LLVM dependency in postgres works, it could be packaged separately from the base postgres server package. The LLVM interfacing code is runtime loaded, and there's no error if "llvmjit.so" is not on the system, even when the server was built with LLVM support. It's basically a packager's choice whether to do so, or not.

Reply on news.ycombinator.com