Ask HN: Backend developers of HN, where and how often do you still use SQL?

SQL makes things sooo much easier, those complex queries are... complex! for a reason, SQL does a lot of the heavy lifting that would take months to code from scratch. Not only that it offers speed, time tested reliability, and pretty much supported on all platforms.

I work at a startup, we are 6 engineers, 2 of us are back-end engineers. I use PostgreSQL everyday. We tried using an ORM, and creating our own ORM, but it wasn't worth it for us. When you are dealing with medium-large databases, you're going to want to use indexes, to do custom queries with joins etc and it's just not worth it trying to use ORMs.

It's not a matter of liking it or being compelled, it is the right tool for the job. The alternatives have the advantage of being accessible to developers who don't even know what they don't know. I think that this article describes the situation nicely: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never....

I had to work on different projects where raw SQL queries where all over the place. This usually happens when the ORM does not help building very large dynamic queries or the developers just want to go the easy way and write the query in raw SQL rather than learning the ORM-specific way of doing it (I have done this myself a lot, to be honest).

In my opinion, I feel more comfortable tuning a raw SQL query to get better performance than tuning the ORM to work in a very specific way to run the very same query and get the performance benefit. However, for easy selects/updates it's more convenient using the ORM and getting the benefit of serializing the results to a domain entity

Every day. Seriously consider using SQL to store your data.

Are you in doubt between a plain file and sqlserver and you think it doesn't worth the hassle of installing a full blown sql server, making backups regularly, etc.? use sqlite.

Define “use sql”?

Most of the time on $client project we use a query builder, so it’s expressing the intended query as methods.

You’d have a hard time using it without understanding what operations you want - it just handles all the repetitive stuff for you.

Then there’s times when we need a query that’s too complex for what the QB methods support, so we use the custom query mode, where we can mix specific parts of a custom query with some of the stuff the QB generates.

I use sql on a daily basis.

Many of my etl processes are based on stored procedures. These are large transfers usually via bulk copy (bcp).

Crud operations are done via orms (Entity Framework) or a light orm, Dapper which requires sql statements at times.

Generally, I try to avoid complex sql statements though they are necessary.

Everyday. Doing CRUD and ETL. My team uses gasp stored procedures for essentially everything. So, we end up writing raw queries and saving them to the DB to be called over and over. Using an ORM like Dapper helps make that map to runtime object easier.

I’ve used several ORMs for different languages. Dapper and stored procedures have become my favorite approach. Like anything, there are trade offs. You end up with logic hidden in the DB or sometimes need to update your procs after you alter a table. If you have a good pattern established for your tables, you can easily autogenerate CRUD procs for each table!

I use it a lot because I'm too lazy to learn new code syntax every time I work with new a framework or language. SQL stays the same so it's more transferable. Besides, once you become an advanced SQL user, you find queries that are harder to build using code instead of SQL. It happened to me a lot when writing Apache Spark code.

We use Postgres so using SQL daily. We have a mixture of pure SQL and Honey SQL[0] in our code base and we utilize jsonb columns as well, which gives us a nosql feel while still using a traditional relational database.

[0] https://github.com/seancorfield/honeysql

Not enough. As my current team is in love with NoSQL and refuse to learn anything related to SQL. But when dealing with legacy stuff, I get to do all SQL related work. Anything in SQL is faster to develop and execute than NoSQL. Only advantage of NoSQL is that you don't need to think about your data, just stuff everything in a json.

Daily and multiple flavours of SQL at that. At the moment it's a postgres, snowflake, mysql and n1ql merry go round.

Our legacy systems use SQL and relational DBs. There's a big push to go to DynamoBD for everything new. We are copying old data into these new systems. It's a real mess trying to slot DB2 or Oracle data into multiple DynamoDBs, and in piecemeal fashion no less.

SQLite is the backend where data goes to be sorted and analyzed and searched in a reasonable amount of time. I tried keeping everything in flat files and generating results with grep but for millions of records it was clear flat files and grep would be far too slow.

use it almost daily. * debugging * seeing how tables are defined * seeing what enums are defined in the db * seeing what the composite keys of the table are * testing if my failure is because of missing data or because the data doesn't match table spec, etc...

it's an exceptionally good language for querying data. One of my favorite languages ever. focused, easy to understand (except the really complex stuff but that applies to all languages).

Every day. PostgreSQL is my favorite application server.

Depends on the project. Mostly for debugging issues. It’s always useful to know.