I must admit, I'm doing it too. But why oh why, people thing that they must use an sql server, when writing a web application framework. It is beyond me.
Some will say, "Well my/pg/ms/any sql server is fast, it it there, it is ubiquous, flexible and everyone is doing itr, so you can find books about it.
Let's tackle these pros one by one in our context.
Fast
Indeed, it can be. SQL server software is usually designed to work with vast amounts of data, stored on some secondary storage. Relational data can be organised, searched, extracted fast. Sure. But. There is always one. A web application framework doesn't know the exact nature/model of the data. It usually builds a palette of primitive types, then does some magic to join those types per application type. You'll find object-relational mappings, sql synthesis algorithms, others, whend dealing with this problem.
So you start introducing more layers. For example you have, at least, this native language to sql query translation layer, which generates, very often, a not very optimised sql statement, which is then translated by the server, then the server does what it does, then that is passed back the channel. And so on. Very often, you'll find that one sql result will be follwed by another, and another, and another.....
So you have double translation, the memory and cpu overheads of the sql server to do the memory<->secondary storage retrieval. Why? because sql solves some of the search problems, and you have a decent language there. But does SQL solve your problems directly, intuitively, whitout ugly hacks? Answer yourselves. My answer is no, not really, I need ugly hacks.
Have you seen an sql server going on an eting spree for resources? No? You haven't done anything interesting yet, or you are an SQL genius.
Ubiquitous
So what? The question is does it fit your requirements, not everyone else's.
everyone is doing it
So what? Can't you think on your own?
Flexible
For describing relational data. It was designed for that. Not for every data model this is natural, although doable, for sure.
Decently fast tree and graph algorithms in SQL anyone? Insert, update, delete, without too much data overhead?
What is you solution for polymorphic types?
Books
Sure there are plenty. Some of them are excellent.
My problems with it
I mentioned already nearly all of them.
Polymorphic data
It usually requires separate queries for each subtype/possible type, then native mergige of the results. A few copies of possibly large amounts of data is involved. Another option is getting all possible in the single result, which means either redundancy in the model (tables) or more joins.
Resourse overheads
It is a waste of resources to run an sql server of any kind, for a small website. For mass hosting the benefits are getting there, but still... How do you justify the double translation? Yes, probably development time, but only if your result code is good.
Hacks
In order to achieve decent performance, with common structures, like trees, you need secondary indexes in sql. Some structures are not really even hackable into decent speed - think about graphs, even loopless ones will have a problem.
What then?
Ideally, you shouldn't need a storage server. Your programming language should do it for you. Ideally, you should have an orthogonal system.
That's dreamland. In realworld, you the optimal tool you can find for the job.
If you have a regurlarly changing data, with a nearly permanent structure, without too complex datatypes, use SQL. There are libraries, speaking SQL, to link into your program, if you don't require a server.
There are benefits from using tools native to your language of choice as well. Your developer wouldn't nessesarily need to understand yet another language to develop decent code.
Or use specialised tools like the Berkley/Sleepycat db. There are others. They have bindings to many programming languages.
