Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm most interested in the features that commercial DBs like Oracle have that free/open-source DBs like Postgres, MySQL, & NoSQL DBs don't. Are things like "a materialized view (1996!), a continuous query, the result cache" available in any free DBs nowadays?

There's more of this sort of criticism in the following old thread, "SQL Databases Don't Scale":

https://news.ycombinator.com/item?id=690656

where a few commenters say (somewhat unpleasant) things like:

- I find that this type of FUD comes about from people that aren't good at designing and implementing large databases, or can't afford the technology that can pull it off, so they slam the technology rather than accept that they, themselves, are the ones lacking. Most of them tend to come from the typical LAMP/SlashDot crowd that only have experience with the minor technologies.

- For me, thousands of transactions per second and 10s of terabytes of data on a single database is normal. It's unremarkable, it's everyday, it's what we do, we have done it for years. And I know of installations handling 10x that. It's only people who's only "experience" is websites that whinge about how RDBMS can't handle their tiny datasets.

- Mr. Wiggins article would be better titled something like "ACID databases have scalability problems, especially cheap ones startups use"

How true are these criticisms nowadays? Is open-source still far behind, or is it (as I think) more than good-enough for 98% of use-cases?

edit: Thanks for the responses, sounds like I'll be trying out Postgres for my upcoming personal project.



> Are things like "a materialized view (1996!), a continuous query, the result cache" available in any free DBs nowadays?

Getting there... http://www.postgresql.org/docs/9.3/static/rules-materialized...

(The rest of his examples are complicated Oracleisms and you'd probably get pretty far with MVs.)


9.3 matviews are a step forward, yet you could probably roll your own matviews with triggers.


The nice thing with materialized views in DB2 for instance (don't know about oracle) is that they are automatically picked by the optimizer to replace a join. So your logical query is - as it should be - completely exasperated from the physical storage underneath. The DBA just puts in a materialized view and the application will speed up magically :)


I think you mean "completely abstracted from the physical storage underneath" :) Although, I'm sure queries exasperate the storage all the time.

Regardless, I had no idea DB2 was so smart. I guess you get what you pay for.


" so they slam the technology rather than accept that they, themselves, are the ones lacking. Most of them tend to come from the typical LAMP/SlashDot crowd that only have experience with the minor technologies."

Behind Facebook and Twitter there's a big usage of MySQL. Not even PostgreSQL, MySQL.

Of course it's a pain for them, but it works and they're profiting from it.

The question is, how much they are saving by not using Oracle or other proprietary DB? They priced themselves out of the web, now they can't "cry to mummy" about it.

"For me, thousands of transactions per second and 10s of terabytes of data on a single database is normal"

It helps when you have dedicated top notch hardware (especially true some years ago) and the startups have to work with EC2 and EBS (ok, there are some better choices, still)


I just looked at the Oracle price list:

http://www.oracle.com/us/corporate/pricing/technology-price-...

Processor License cost (excludes support):

* Standard Edition: $17,500

* Enterprise Edition: $47,500 (that's the one with Materialized View Query Rewrite)

* Partitioning option: $11,500

* Advanced compression: $11,500 (basic compression is apparently slow?)

Per processor.

This is why all these other databases exist. Very few businesses, certainly not many startups, have the kinds of value of the data stored to warrant that kind of cost.


Yes, very expensive. However, if you're a bank, you may not need too many servers and 50k per server is change.

I believe in the beginning of the web, Oracle wanted to push a per-user pricing model.

Yes, if your website has 10 users, it pays 10x$PRICE, 100, 100x$PRICE

Nobody could work with that (with Oracle)


It all comes down to cost barrier to entry, it's a shame IBM mainframes are still so damn expensive.

Perhaps if somebody could offer {DB2|Oracle|Informix|Sybase} As A Service, like what many providers do with PostgreSQL and MySQL, it would be a different story for startups.

My profression involves moving MSSQL and Sybase databases to MySQL and MariaDB, then I go and read some of the features from the article in Oracle and DB2 documentation and think to myself "I ain't helping fucking nobody", the higher-ups in enterprise and startups usually only see upfront costs, not long term benefits.

As per your first question; they are getting there. PostgreSQL now has a built-in function for managing materialised views, in MySQL/MariaDB that is still hand-rolled.

MariaDB however does have Virtual Columns and Dynamic columns (to tackle nested tables, as per the article).

Look to MariaDB for the MySQL developments, as Oracle are bringing very little to the table in terms of matching MySQL features to Oracle (not surprising). But they are resolving important security, and infrastructure issues and improving InnoDB heavily.

Also PostgreSQL does have HSTORE, for storing JSON data types, very tasty.


There are a lot free DBs options, so I'd bet a lot against anything but the most esoteric feature being only available in a commercial solution.

The foundation of CouchDB queries are materialized view / continuous query. PgPool provides result caching.


> I'm most interested in the features that commercial DBs like Oracle have that free/open-source DBs [..] don't. Are things like "a materialized view (1996!), a continuous query, the result cache" available in any free DBs nowadays?

I cant answer your question, but looking for feature X in other products is the wrong approach IMHO. You're often better served by looking at what problem feature X is solving, and how that problem is other places. Sometimes the problem doesn't even exist.


You're often better served by looking at what problem feature X is solving, and how that problem is solved other places




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: