
Why old-school PostgreSQL is so hip again - bjourne
https://www.infoworld.com/article/3240064/sql/why-old-school-postgresql-is-so-hip-again.html
======
joncrane
Is Postgres really perceived as "Old-School?" I mean it's at least as modern
and hip as MySQL these days.

~~~
SAI_Peregrinus
It came out earlier than last week. Definitely "old-school" for some.

~~~
astrodust
Three JavaScript frameworks and a dozen political scandals ago.

------
wenc
The biggest gripe I've had with Postgres (and I mention this elsewhere) is the
lack of a decent GUI/IDE.

But as Datagrip matures, the landscape can only get better. Datagrip is not
free, but I'm willing to pay for something that works better than pgAdmin.

There are some exciting things happening in the Postgres space. Outside of
Citus for scaling out, TimescaleDB has a plugin that makes Postgres a strong
contender in the time-series database space. Temporal joins have always been a
problem with NoSQL time-series databases; otoh joins are what SQL databases
have traditionally been optimized for. It'll be exciting to have a large-scale
datastore where you can easily combine and recombine different time-series in
a single query.

~~~
sametmax
PGadmin and DBeaver are nice, just in case you didn't tried them.

~~~
mynewtb
Pgadmin went downhill, the new version is borderline unusable.

~~~
Avernar
Yep. I'm still using pgadmin 3.

------
Sevii
Postgres fills a niche that has a lot going for it. It’s standard SQL with
transactions so it’s easy to code against compared to Nosql like Cassandra.
There are lots of powerful extensions like JSON and full text search. And you
can scale it pretty far.

~~~
sidlls
Postgres is likely suitable for 90% (or more) of the crap "engineers"
currently fall all over themselves to implement Kafka, Spark, and whatever
other bizzword laden "big data" or "machine learning" resume driven
development for.

It's not a niche.

~~~
3pt14159
I'm still trying to find an engineer that can explain to me why they use Redis
for job queuing over Postgres.

Redis for HTML caching: Cool.

Redis for queueing: Are you _really_ sure you need the performance gain?
Really? You can do 10k writes per second with Postgres (100k per second with
COPY). If you need more than that fine, but for 99% of web apps out there it's
just one more moving piece that probably doesn't get included in your backups.

~~~
stevenwoo
I was looking at that choice for my latest project and the gem recommended
(resque?) only using Redis for the job queuing at the benefit of much higher
performance over something like delayed_jobs using postgresql in jobs. It
didn't seem worth it as job queueing was not the main feature of the server. I
suppose if one were doing some sort of real time feature where you had to
queue things off a Rails API response thread it would make sense but wasn't
doing that for now. But just judging by the number of downloads, the Redis
based job queue is possibly more popular for some reason.

------
selimnairb
Is it possible that a rise in geospatial applications is partly a driver of
Postgres’s rise in popularity? PostGIS seems to be the best option for storing
geospatial data in an RDBMS (open source or otherwise).

~~~
cname
Anecdotal, but PostGIS is _the_ reason I started using Postgres several years
ago in some of my own projects, which later came in handy at different jobs.
At one place, we standardized on Postgres partly because of PostGIS.

I think Django has had some influence too, since they've always recommended
Postgres.

~~~
Boothroid
I selected PostgreSQL for a geo project recently. Still haven't got my head
around tuning, but apart from that I've found it great to use. I use psycopg2
to connect from Python. No nasty surprises in use, and found that all my
pidgin SQL translated easily. Also worth knowing that ogr2ogr supports
PostgreSQL and is an awesome tool.

------
teddyh
I wish WordPress would support it. It would make it easier for me to suggest
PostgreSQL for people with simple web hosting needs.

------
greenhouse_gas
Looking back, I never understood why it didn't win the database wars in the
90's against MySQL (in the famous LAMP stack)? Was it that it was harder to
administrate?

~~~
combatentropy
Based on the other replies about MySQL being simpler and faster, it makes me
wonder again why SQLite didn't win.

~~~
SQLite
SQLite was late to the party. The first code for SQLite was laid down in 2000,
years after MySQL was already well-established in the LAMP stack.

Also, SQLite is embedded, not client/server. That means that the application
needs to run on the same machine that holds the data. And because there is no
server to coordinate access, concurrency is necessarily limited.

On the other hand, SQLite arrived just in time to get picked by smart phones,
and is consequently the most-deployed database software in the world. There
are far more instances of SQLite running today than there are MySQL instances.

------
dunk010
Not everyone jumped on the NoSQL bandwagon. Software development is a horrible
gaping maw of fad-driven, ill-thought-out crap.

~~~
geebee
Yeah, what a disappointment.

In the early days of NoSql, a lot of dev were still shoehorning graphs,
objects, or giant look up tables into SQL database, and yes, it turns out that
there are some wonderful databases to store and query this sort of data that
don't rely on a relational model.

And then... yep, a bunch of magpies decided that SQL shouldn't ever be used.
It's important to point out that plenty of people who pioneered and promoted
graph databases, object databases, and so forth didn't go down this rabbit
hole. When the data was relational, plenty of these folks were all for
relational databases.

But I don't think you can claim the "NoSQL => never use SQL => SQL is
obsolete" crowed was just a few outliers. This opinion infected a lot of
software development organizations, and did plenty of harm.

I love SQL, but let's not get too enthusiastic about sending the pendulum
swinging back the other direction, even if tempting to watch it knock a few of
the overly zealous NoSql types off their perches. Trust me, I still feel a
flash of anger inside when I think of some of the arguments I had to go
through when I advocated for relational SQL databases. But I don't want to be
that guy myself - plenty of non-sql data bases are really well conceived and
designed, and are ideal for the problems they address.

~~~
bunderbunder
I would lay some of this at the feet of the fad for object-relational mapping,
too.

Trying to deal with object/relational impedance by sticking an object-oriented
API in front of the database, and then using that to shoehorn OO ways of
organizing and accessing data into an RDBMS, is a great way to place an upper
bound on what kind of performance you can get out of the database. It also
makes (what should be) routine schema migrations much more painful than they
need to be. I think that that can explain a lot of the perceived success
people were seeing with many document stores.

~~~
geebee
That's a really good point. I have, certainly in Rails projects[1], seen the
strangest databases. They are SQL databases that are useless outside the rails
application. You actually can't query them in a relational sense, you have to
go through the app and its methods of querying, transforming, and merging
data, before you understand what it means.

In short, the developers more or less used the ORM to serialize and object and
write it out to disk. The persistent data basically makes no sense on its own,
it has to repopulate the objects before it can be accessed in any meaningful
way. There's little doubt that the devs behind these project had very little
understanding of what an RDMBS actually _is_.

And if you don't, then I suppose NoSql makes sense, because your data is
_never_ relational - not because it the relational model wouldn't be helpful,
but because the developer can't see the relational model in the data stored,
and is incapable of structuring it this way.

I remember this idea (paraphrasing)[2] - the data will outlast the
application, and the application will most likely outlast the developer.

To me, this led to a design principle - the database should always be useful
outside the context of the application. If you want information about the data
you're storing, the DB should be a very, very useful place to get it. I'm not
ruling out the value of the app! There are lots of ops you'd want to do as a
combination of code and data, lots of UI, plenty of things. But if your data
is useless and nonsensical unless your app transforms it, that is _probably_ a
sign of a big mistake[3]

[1] I love rails, and I like ORMs. They save me so much typing compared to the
old days of JDBC. It turns out it's not all that hard to create a well
organized relational database through generators, and if you prefer to design
the DB separately, it's not hard to map models to db tables. It really only
gets out of control when people are essentially designing an RDBMS through
generators and an ORM, but have no idea what idea what it all means on the
backend.

[2][https://blog.jooq.org/2014/01/02/why-your-data-will-
outlast-...](https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-your-
sexy-new-technology/)

[3] _probably_

~~~
bdcravens
> That's a really good point. I have, certainly in Rails projects, seen the
> strangest databases. They are SQL databases that are useless outside the
> rails application. You actually can't query them in a relational sense, you
> have to go through the app and its methods of querying, transforming, and
> merging data, before you understand what it means.

When I converted our application to Rails, I had a database that was pretty
home-grown, as we were using a language/framework where you tended to write
raw SQL. While I was able to tweak the model files to work with our schema, in
most places I found it too challenging to construct ActiveRecord queries, and
ended up writing a lot of raw SQL (or rather, copying it from previous
iteration). Initially I thought I was doing it wrong because it wasn't Railsie
enough, but realized that our database is our asset, and Rails is secondary.
We do a lot of ad-hoc querying and report writing, so I definitely think
database-first is the way to go in our use case.

