Hacker News new | ask | show | jobs
by alceta 3194 days ago
If anyone even remotely involved with the maintenance and development of pg reads this thread - Thank you! - for all your efforts in building and improving a first class product that keeps me amazed at the strides it takes with each major. release.
5 comments

Truly. We've recently moved from Oracle (after using it for 15 years) to Postgresql. It's like a breath of fresh air. The documentation for Postgres is unbelievably superior to Oracle. So far its performance is equal to or better than Oracle. We had to go through and rewrite thousands of queries, but the sql syntax of Postgres was always simpler and more logical than the equivalent in Oracle (I think Oracle has too much baggage from being around too long). All in all I'm so impressed by Postgres. I'm sure there are features in Oracle that Postgres doesn't have that keep people on Oracle, but I would imagine that the vast majority of Oracle installs could be moved to Postgres.
Do you plan to write more about the migration, like a blog post? That would be very interesting to read.
This needs to become a thing. Where people produce writeups on Oracle To Postgres, and how much better it is; under something like #RunsMuchBetterWithPostgres ...

It is strange that there aren't more writeups on Postgresql migrations.

Yandex had a good one. Posted here a long while ago: https://news.ycombinator.com/item?id=12489055

> It is strange that there aren't more writeups on Postgresql migrations.

It's probably because switching databases is very painful and rare.

I would think that not having to pay the Oracle/MS/Sybase/Teradata licenses are a good enough incentive...

Speaking of economic incentives.

That could be a thesis topic for my hereto unwritten PhD in Behavioral Economics:

"Choosing to pay" What are the behavioral aspects of top leadership - Why do people still chose proprietary" A quantitative case study."

If I had to wager, it's support. Oracle/MS generally provide much better support that open source software.
This. It was worth it, but it still took us the better part of a year.
It would take a lot more than a single blog post. It would probably take dozens of blog posts (or a book). It took us the better part of a year. There are just so many things that have to be taken into consideration and learned.
I'd be very interested in this after years of working with Oracle (and SQLServer), I know a little Postgres and would like to learn more.
+1 to this.
I think most Oracle installs are from the days ram was limited and incredibly expensive.

Right now anyone can afford a db server with 128gb ram, enough to solve most problems #YourDataFitsInRam

>> I think most Oracle installs are from the days ram was limited

Could you explain ?

Personally I use Oracle (and hopefully one day PG) because it gives me guarantees on data integrity and these guarantees help me to think about my programs more easily.

Oracle started before microcomputers (PCs) were anything but toys. In 1983, they were multiplatform: mainframes and minicomputers. a 1983 minicomputer might have 2 CPUs, each good for 2 MIPS, 8 MB of RAM and primary storage of as much as a gigabyte or two of disks.

In the early 2000s, a serious database machine -- say, a Sun E10000 - had up to 64 CPUs, running at 400-500MHz each, 64 GB of RAM, and a huge cabinet full of disks.

Now you can call up a SuperMicro VAR and order a 64-core AMD EPYC server with 2TB of RAM and 4 TB of NVMe drives, that talks to other machines over a 100Gb/s ethernet, for a price around the same as a used Tesla S85.

If your database is under 2TB, it all fits in RAM on commodity hardware, where commodity is defined as "anyone with a credit card can order it without even talking to sales".

>>> Oracle started before microcomputers (PCs) were anything but toys.

I didn't know that. At that time I was discovering Applesoft basic :-)

Oracle is the real elephant in the room, all pun intended.
Seconded. Postgres is such a high quality project in so many ways. I'm rarely left wanting when using it, and very often pleasantly surprised.
agreed. after years of having used Oracle and SQL Server at work, to find I could have a working database in about 10 seconds with

sudo apt-get install postgresql

was amazing to me!

In 2015 we upgraded from Oracle 10 to 11. It took two weeks.

I took the chance to upgrade our PostgreSQL instance. It took less than an hour. It was a smaller database, but the difference in complexity was still impressive.

SQL Server on Linux in a container is just as easy now:

   docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=password' -p 1433:1433 -d microsoft/mssql-server-linux
EDIT: Or with apt-get too:

   sudo apt-get install -y mssql-server
https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-...
Those aren't all of the instructions for apt-get. The full instructions are on https://docs.microsoft.com/en-us/sql/linux/quickstart-instal... and appear to consist of:

  curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
  sudo add-apt-repository "$(curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list)"
  sudo apt-get update
  sudo apt-get install -y mssql-server
  sudo /opt/mssql/bin/mssql-conf setup
  sudo apt-get install -y mssql-tools unixodbc-dev
  echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
  echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
  source ~/.bashrc
And at that point, you have a limited period trial license of a release candidate version installed, and so once you want to use it for production, you have to start dealing with license management issues, which could limit your ability to easily set up dev envs, test envs, hot spares, etc.

All of that is on top of the issues of how heavyweight it is due to containing a platform abstraction layer that consists of a very large amount of Windows running in user mode, as discussed by others in this thread.

Yes, you have to add the repo, the same as if you wanted the latest postgres bits on any distro. You also have to edit configs for both and you can also choose to install extra tools for both.

I'm surprised at how many people seem to have taken issue with a simple comment. Postgres is easy to install... and now so is MSSQL compared to the complex slow GUI installer they had before. Maybe it'll help the original commenter, maybe not. Let's just leave it at that.

Debian and derivatives have it in repos by default. Please don't make claims like those.
That's more to do with the OS than the DB, and many repo entries are outdated. MSSQL hasnt existed on Linux before, but either way:

> I'm surprised at how many people seem to have taken issue with a simple comment.

Let's not let this devolve into a db war. This submission is about PostgreSQL 10. Your parent expresses how easy it is for them to get PostgreSQL up and running in their environment—no comparison saying that others are bad (edit: though they did have some difficulty in the past). It's great that you've got a good solution that works for you! And I'm sure there are other ways of doing this as well for other dbs. If you have experience with PostgreSQL and SQL Server features that you'd like to compare that are relevant to these PostgreSQL release notes, please do share them constructively. I'm sure there are people that would be interested in hearing about them.
parent here. yeah SQL Server is pretty nice to work with as well!
Where's the db war? The comment was implying that MSSQL wasnt as easy to install and I offered advice for the latest version. Neither database is really production ready with a 1 line install but it seems you're finding conflict that doesnt exist.
That strikes me as being comparable only at the most superficial level. I started that SQL Server container and it's using 825mb of RAM (according to systemd-cgtop), just sitting there idle with no data in it. I started a Postgres 9.6 container also using their official Docker container and it's sitting idle at 58mb of RAM.

Insult to injury, if you're using Docker in a VM (as you must on a Mac) the instructions on that Docker Hub page say you need a minimum of 3.25GB RAM dedicated to the VM. That's quite a heavy lift if all you want is a database instance for local development.

And then sure, you could run SQL Server on Linux for your production instances, but you're well off the beaten path. You're going to have to roll your own infrastructure rather than relying on AWS RDS, Google Cloud SQL, Heroku, etc etc. And the moment you have a performance problem the first advice you'll hear seems likely to be "try it on Windows and see if it reproduces there".

That 58Mb RAM number isn't necessarily a good thing - something postgres has regularly fought against adoption-wise is that the defaults exist to be sane on a shared machine, not provide maximum throughput on a dedicated database server. While I appreciate this choice personally, I also suspect a good container default would idle higher.

(I'm a huge pg fan if that isn't clear - just ...)

SQL Server does use it's own mini-OS layer and this what lets it virtualize and run on Linux too, so there are higher system requirements.

It seems you're just guessing on that last part though - SQL Server has been in production for decades and already has lots of tooling and there are even new CLIs available for the Linux environment. Production SQL Server comes with support from MS, you're definitely not on your own nor will they just tell you to run it on Windows, this is simply not how enterprise support works and they would have a hard time staying in business with answers like that.

We can discuss support issues but it's best to leave the assumptions and hyperbole out of it.

"Assumptions and hyperbole"? That MSSQL isn't available as a service like RDS? That tooling and integration that's been building up for decades around PG (or Mysql/Maria for that matter) doesn't exist? These are just facts.

I'm sure you're right that MS would be happy to sell support. What I don't see is a reason to care, unless I run in to a Windows app that can't use another DB that I suddenly need to run under Linux.

I'm not sure what you're arguing. MSSQL is available on RDS and to quote the parent comment:

> ...SQL Server on Linux for your production instances, but you're well off the beaten path...first advice you'll hear seems likely to be "try it on Windows and see if it reproduces there"...

You dont think this is hyperbole? Have you actually used SQL Server or Microsoft support before? They do not treat enterprise customers this way and both Linux and MSSQL have plenty of tooling available. There's nothing challenging here.

> What I don't see is a reason to care

You're not the target market then. MSSQL has some compelling features and a big ecosystem, adding cross-platform support and a much easier installation process only helps customers with more options for deployment.

You left out the licensing step, working out what license you need is it's own time sink.
That's not as easy in at least two ways: having to use docker and know that command line.
That command line is basic docker usage. Containers are far easier and cleaner than apt/yum installations at this point but you can just do this too:

   sudo apt-get install mssql-server
I had issues with the docker container on Debian 9. I think the container is only tested on Ubuntu.
And they didn't even ICO
Third!