[MaxBarraclough]

Yes he makes similar points there. A few scattered critical thoughts:

* I don't see any problem with stored procedures. They can make good sense for, say, auditing, as well as for performance.

* People describe their software systems as "Using Oracle" because it matters, not because their design is stupid. It tells me that Oracle skills are relevant, for instance.

* NoSQL is generally, in my experience, awful and chaotic, rather than liberating. Lots of good work has gone into making serious grown-up relational databases. Schemas, normal forms, constraints, rigorous work on the ACID properties. Something like MongoDB is just sloppy amateur-hour by comparison.

* In the YouTube video, he says that solid-state drives render relational databases obsolete. This strikes me as absurd. Not even ultra-fast SSD storage technologies will do that. The relational model is effective, and the associated DBMSs still well justified. Joins belong in a query language, not in imperative code. Why would you want to try managing a huge complex dataset manually?

[0] https://en.wikipedia.org/wiki/3D_XPoint

(Edit: formatting)

[AtlasBarfed]

Yeah, I have changed my opinion of stored procs to :

If you have a proprietary database, stored procedures are awful. AHEM ORACLE.

[NotSammyHagar]

Yeah, seems like he vastly overstates things. ssds are great for relational databases. They all use them.

[jbergens]

I think the point is that you might be able to build something else than a standard relational db and make it faster.

Something like VoltDB but there are other solutions. There used to be some blogs about their architecture and how they could avoid a couple of steps a normal RMDB needs that takes a lot of time.

https://www.voltdb.com/why-voltdb/

[MaxBarraclough]

> I think the point is that you might be able to build something else than a standard relational db and make it faster.

I sincerely doubt that.

For it to be useful in real world situations, you'd have to build your own highly flexible, scalable, rock-solid, high-performance data-management solution, ideally one which enables the user to use a declarative means of expressing queries.

This is, of course, a DBMS.

If you build one which imposes structure on the data, you've got either a relational DBMS, or an object DBMS, or some other kind of well-studied database solution... except you've rolled your own from scratch, without input from database experts, so it's going to be a disaster.

Unless you're someone like Microsoft, Google, or Amazon, you pretty much can't build one of those. It costs tens of millions. It takes a huge amount of testing, for obvious reasons.

I really don't see any argument for not using a mature database system for managing a typical company's data.

Of course, if we aren't talking about a full-scale database that has to cope with a huge amount of messy mission-critical data in a changing business environment, then the game changes, and sure, you might have a chance just writing something yourself.

Netflix's video-streaming CDN ('OpenConnect'), for instance, obviously isn't powered by an RDMS. They put in a huge amount of highly technical work building their own finely tuned technologies to pull data off the disk and get it to the NIC with minimal glue in between. But that's Netflix, and virtually no real companies face that kind of challenge.

Also, VoltDB looks like a streaming DB technology. Isn't that both an DBMS (rather than a means of rolling-your-own), and very niche? I don't see how it's relevant here. If it's really able to serve business needs better, then great, but it's still a complex-DBMS-as-a-product.