Hacker News Reader

Comment by therealarmen | Hacker News Reader

Congratulations to Datastax's PR team, they did a wonderful job getting this reporter to pit them against almighty Oracle. In reality Oracle will die from a thousand cuts, not just NoSQL but other cheaper (and more reliable) alternatives such as SQL Server, Postgres, etc.

View on HN

Datastax, Datastax. Must have appeared 20 times in the piece. I'm sure they are a great company but Oracle's real problem is Postgres (and, to a lesser extent, SQLite and the various MySQL forks). Oracle might want to consider paying $1B to the Postgres devs to sidetrack development for a few years like they did with MySQL.

> Oracle might want to consider paying $1B to the Postgres devs

There's no single Postgres dev, it's been community-driven from the start and the various postgres companies mostly provide support. So there's nobody to pay $1bn to really.

If you look at the contributors page[0], out of 6 "core devs" there are 5 different companies, with EnterpriseDB being "overrepresented" at 2 core from the company, plus a pair of "major contributors" out of a truckload.

And these people are probably Postgres devs first and foremost. Not Tom Lane or Josh Berkus, but even if Oracle bought out EnterpriseDB they might just cash in and work on Postgres from an other company.

[0] http://www.postgresql.org/community/contributors/

MySQL is a very very small drop in the ocean that is Oracle. Competing with Postgres is a non-issue for them. Oracle's big problem is SAP.[1]

[1]http://www.informationweek.co.uk/software/enterprise-applica...

Somehow

- sql server

and

- reliable

don't really belong in the same sentence.

Do you have any citations or information to indicate that? My understanding from the sqlserver DBAs that I know that the platform is rock solid. Have you heard otherwise? Genuinely interested.

I've seen several sql server shops with severe performance problems where the in-house DBAs had no clue what had hit them. Different DB engines deal with multi-version read consistency in different ways, Postgres does a defensive copy-on-update, Oracle falls back on rollback segments; unfortunately sql server escalates page locks to table-wide locks, and then performance goes downhill from there.

If your friends don't experience any problems, I would venture to guess they must be running small databases, or databases where the workload is 90% reads 10% writes.

Having actually deployed and used SQL Server extensively, I know how it handles "multi-version read consistency": As I tell it to:

http://msdn.microsoft.com/en-us/library/ms173763.aspx

In addition to setting a database level default, you can even have it behave differently per connection. Snapshot isolation will never lock, period.

SQL Server is actually quite capable, and has the fantastic tooling that cheaper alternatives like PostgreSQL lack.

Care to say how big your database is, and what your workload looks like (reads vs. writes)?

SQL Server 2008 and upwards are incredibly solid, we use it extensive at my current work place doing telecoms stuff and have very few issues.

It's not what I would have picked (I come from a Linux and Oracle background), but I've been very impressed.

Agree. TSQL is painful compared to pl/sql. But SQL Server has always been solid in my experience. That may be because it came from outside Microsoft (Sybase) but by now I'm not sure how much of the original implementation is still in the product.

Toshio, your comment below is [dead] so I can't reply, but the databases vary from 10's of GB to multi-TB depending on their use.

The DBs are often very write intensive on the master, with as much reading as possible done on slave databases, with tables heavily normalised to try and reduce the disk performance hit.

Most of the extremes of the setup are there for legacy performance reasons - The newer systems using SQL Server 2008 or 2012 and SSD drives generally don't need it, and we're moving towards a less normalised setup.

EwanToo, that is very interesting.

Also, since the entire discussion started by me questioning the reliability of sql server, can you say how many days your database server stays up between reboots?

It would certainly be months or years, depending on patches really rather than an outage.

SQL Server seems maybe too focused on usability.

Oracle's query interpreter, for example, is extremely anal, you have to commit everything and Oracle is likely to reject your queries if they are slightly off, which helps catch errors.

SQL Server follows more of a "Do What I Mean" approach, even going as far as to perform implicit type conversions for you, which is fine until it guesses wrong. Then, instead of rejecting your query, it screws up your data.

And don't tell me I can configure it to behave differently, it should work correctly out-of-the-box.

Reply on news.ycombinator.com